Интересно, что у меня оказался Wireguard быстрее даже на смартфоне, где он работает в пространстве пользователя.
И адрес клиента в настройках сервера не задаётся, более того, он может меняться во время работы без разрыва соединения. Там задаётся адрес внутри VPN, но он вообще может быть внутренним и никак не выдаёт местоположение пользователя, а также публичный ключ (которого недостаточно, чтобы подключиться от имени клиента, в конфиге которого лежит приватный ключ).
Преимущество OpenVPN в том, что он поддерживает разные способы аутентификации и динамическую выдачу IP-адресов. С Wireguard вам понадобится какой-то свой сервис, который реализует вход пользователя в систему (например, вводом логина и пароля в веб-форму, доступную без VPN по HTTPS), генерит для него конфиг, прописывает туда IP и ключи, добавляет пользователя в конфиг сервера — а в OpenVPN это доступно из коробки. Поменялся IP на стороне пользователя — ему надо поменять конфиг, а OpenVPN просто выдаст новый.
Тогда зачем переживать за диапазон 6 ГГц? Для многоквартирных домов лучше подойдёт стандарт типа WiGig с маломощной точкой в каждой комнате, для загородных домов, где другие точки не мешают, будет хватать и 5 ГГц (может и 2,4 ГГц тоже, если дальность важнее, чем скорость). Для уличных точек из-за бóльшей дальности будет лучше подходить 2,4 ГГц.
Не хочется тянуть кабели в квартире? миритесь с неизбежными физическими ограничениями — если точка доступа пробивает стены, ей будут мешать соседские точки.
Не думаю — скорее всего развитие беспроводных технологий просто упёрлось в нехватку частот. Чем больше скорость передачи, тем больше нужно частотной полосы. Причём увеличивать частоты бесконечно тоже не получается — падает проникающая способность.
Мобильная связь на высокочастотном 5G была бы очень неудобной из-за неустойчивого сигнала. Даже на 4G (1.8 ГГц) это сильно заметно, на даче есть место, где на возвышенности очень хороший сигнал, а в 200 метрах в кустах связь пропадает. На 5G добиться устойчивого покрытия везде было бы гораздо сложнее.
Даже если бы можно было отвести под связь вообще все существующие частоты без ограничений, все равно бы упёрлись, но чуть позже.
WiFi в многоквартирных домах будет работать плохо всегда, если точка доступа будет в каждой квартире, и на 5 ГГц, и на 6. Возможно как-то могло бы помочь взаимодействие между точками доступа в одном доме. Или увеличение частоты до такой степени, чтобы сигнал не проходил сквозь стены, с установкой маломощной точки доступа или излучающего кабеля в каждой комнате.
Это похоже на переносимость телефонных номеров. Без переносимости получается похожая зависимость от окружения: человек хотел бы сменить оператора, но ему приходится пользоваться старым номером, чтобы оставаться в контакте со своим окружением.
Операторам переносимость тоже невыгодна и они не стали бы добавлять её по своей воле. До этого дошло с политической волей государства и общим запросом пользователей на такую функцию.
Почему в случае с мессенджерами должно пойти по-другому, и зависимость от поставщика для поддержания общения должна сохраняться? только потому, что мобильные операторы стоят под государствами, а мессенджеры нет, а пользователям проще поставить ещё одно приложение, чем подключить тариф другого оператора — они же не платят за это деньги, а расходуют только немного трафика и заряда батарейки телефона? Или есть ещё какое-то принципиальное отличие между телефонной сетью, email и мессенджерами с соцсетями, из-за которого первые два способа общения интероперабельны, а последний нет?
Подарок нашим депутатам — только как они заикнулись о цензуре со стороны интернет-гигантов, они им подкинули такой шикарный аргумент, зацензурив самого Трампа по явно политическим причинам.
Но мне кажутся мерзкими обе стороны — и наши с борьбой с цензурой с помощью своей цензуры, и интернет-гиганты, потерявшие даже видимость нейтральности и использующие свои технические возможности для продвижения каких-то политических взглядов (как Google решил заблокировать приложение, используемое сторонниками Трампа).
Мне кажется, что интернет-гигантами должны заняться антимонопольные органы развитых стран. Их приложения образуют разновидность монополии, когда потребитель вынужден использовать их приложение для общения просто потому, что его окружение использует это приложение (например как Whatsapp). Почему чтобы связаться с пользователем Whatsapp или Facebook, мне нужно их приложение? Это ограничивает мою свободу выбора, как потребителя. Я считаю, что мне Whatsapp не нужен, но через него передают какие-то интересующие сведения люди из моего окружения, поэтому я вынужден его использовать. При этом корпорация Facebook может иметь доступ к моим данным и даже пытаться мною манипулировать в каких-то своих целях. Почему нельзя сделать IM или голосовое общение так же, как в электронной почте? где есть независимость от поставщика — у одного почта на Гугле, у другого на Яндексе, у третьего вообще на своём домене, и все они могут связываться друг с другом. А если у одного только Whatsapp, у другого Telegram, у третьего ВК — они уже не смогут друг с другом связаться!
Необходимо добиваться стандартизации для IM и голосового общения, сделав обязательными интерфейсы в виде открытых и стандартных протоколов (например, Jabber для IM или SIP для звонков) для мессенджеров с определённой аудиторией, чтобы пользователям не приходилось ставить определённое приложение только потому, что его знакомые используют его.
В таком случае корпорации не могли бы легко блокировать сторонников Трампа или кого-то ещё, сторонники могли бы просто запустить Jabber сервер на своём домене и продолжить общение там, при достаточной распространённости Jabber по сравнению с Facebook и т.п.
Команду обрезки по времени нужно дополнить тем, что если начало обрезаемого куска не попадает на ключевой кадр видео, начало видео может быть смазано, это выглядит некрасиво.
Там был параметр, если мне память не изменяет, -noaccurate_seek, по которому FFmpeg старается сдвинуть начало обрезаемого куска так, чтобы оно на ключевой кадр попадало. Если же нужно точно задать при этом время начала, можно сохранить отдельно часть от начального кадра до следующего ключевого кадра с перекодированием в тот же формат, чтобы кадры перекодировались начиная с ключевого, а потом часть с ключевого кадра без перекодирования, и объединить их.
VNC через браузер работает не напрямую, а через прокси, который работает через WebSocket — тоже стандартный протокол, поддерживаемый в разных браузерах.
Да ничего страшного не случится. Операторы для реализации этого предложения введут тариф "социальный" с бесплатным доступом к ограниченному списку сайтов, но с ограничением скорости до 128 кбит/c, чтобы прочитать новости можно было, или оплатить что-то, зайти на госуслуги, передать показания счётчиков, а музыка и видео, а также удобный доступ без ожидания были доступна только платным пользователям. Так, как это делает Yota, где есть бесплатный интернет на очень маленькой скорости 64 кбит/c, но даже без ограничения по сайтам. Смысл этого в том, что ощущение неудобства от пользования таким интернетом стимулирует пользователя перейти на обычный платный тариф. Эти пользователи и оплатят такой бесплатный доступ, тем более из-за низкой скорости он не даст значительной новой нагрузки на сеть.
И ещё один тест. Запустил noVNC, подключался с EEE PC через браузер — производительность нормальная, ничего не тормозит даже на слабом железе! Но нет звука, VNC его не поддерживает.
Для стриминга игр звук всё же желателен. Лучше подумать в этом направлении. На сервере звук можно перенаправить через PulseAudio на прокси, который через webrtc будет отдавать его клиенту. На декод и воспроизведение звука много ресурсов не уйдёт (тем более в ограниченном качестве 8000 Гц — для старых игр этого достаточно).
Ещё для теста запустил Дум с EEE PC на сервере через обычный VNC. Никаких тормозов не наблюдалось, игра запустилась с достаточной скоростью. Может быть, и вам лучше попробовать вместо ffmpeg попробовать использовать VNC или другой подобный протокол с более высокой производительностью? VNC клиенты, работающие через браузер, существуют, Apache Guacamole например.
Потестировал ещё.
На сайте js-dos.com есть аналогичная возможность запустить игры для DOS в браузере через JS. И там даже на EEE PC Дум запустился, хотя шёл с большими тормозами, играть было неудобно. В простые игры типа Тетриса игралось нормально.
Я также попробовал запустить стриминг Дума на нормальном ноутбуке. Игра запускается, ввод обрабатывается, тормозов нет, но иногда неприятно смазывается картинка. Локальный режим лучше.
Интересно, я решил проверить, и у меня игра запустилась на стороне клиента, через эмулятор JSDOS. Я даже пробовал сетевой кабель выключить, и игра продолжала работать.
Правильно я понял, что для игры по описанной в статье схеме нужно использовать турбо-режим? а в обычном игра обсчитывается только на стороне клиента. Я попробовал поиграть в DOOM в обычном режиме и не почувствовал никаких тормозов. Но у меня мощная машина, попробую на слабой.
На слабой (проверял на EEE PC 901) обычный режим не запускается вовсе, зависает на "JSDOS Starting". Турбо-режим запускается, но не реагирует на ввод.
Пробовал на мобильном (среднем samsung galaxy 2018 года) — и в обычном режиме производительности достаточно, чтобы поиграть в DOOM.
Версия браузера на обоих устройствах (нормальном ноутбуке и старом EEE PC) одинаковая (Firefox 84.0.1). Возможно, старенькому EEE PC просто не хватает производительности. Если бы я взял устройство помощнее, чтобы хватало мощности на турбо-режим (на обработку ввода с клавиатуры и декод видео), ему скорее всего хватило бы мощности и на обычный локальный режим.
Мне кажется, что трудно найти вариант использования, при котором стриминг для таких не очень ресурсоёмких задач, как старые игры, имел бы преимущество перед локальным выполнением. Если устройство слишком слабое, то на нём и стриминг не пойдёт комфортно. Если оно достаточно производительное, на нём лучше пойдёт локальный режим. Если среднее — трудно сказать, в зависимости от сетевого подключения и загрузки сервера. Стриминг или терминальный доступ имеет преимущество перед локальным выполнением лишь тогда, когда запускаемая задача требует достаточно высокой производительности, на слабых задачах его преимущества не очевидны.
А если сделать кэш на энергонезависимой памяти? например, RAM памяти с батарейкой или SSD небольшого объёма с небольшим размером блока и большим числом допустимых перезаписей?
тогда мы можем писать на основной диск по настроению (или после заполнения кэша), но при внезапном отключении питания данные не потеряются. И этот процесс будет контролироваться операционной системой (например, если приложение последовательно пишет данные большими блоками, то их можно сразу сохранять на основной диск, а если пишет вразнобой мелкими блоками — как-то объединять их в кэше и потом переписывать на основной диск).
А если взять обычную файловую систему, но увеличить размер кластера (допустим до 1 Мб), чтобы он совпадал с размером блока записи/стирания? если нужно хранить много мелких файлов, чтобы место не пропадало, можно обойтись костылями вроде squashfs на диске одним крупным файлом + overlayfs в памяти, файлы обновляются в памяти, а при фиксации данных на диске squashfs обновляется и данные пишутся этими крупными блоками. Если изменений немного по сравнению с общим размером каталога, лучше записать отдельный squashfs с изменениями вместо того, чтобы обновлять основной.
Реальная система может использовать не костыли со squashfs/overlayfs, а что-то другое, но работающее по такому же принципу, собираются блоки данных из изменённых данных большого размера в памяти, потом пишутся на диск сразу большими блоками. Недостаток — данные долго хранятся в памяти и при отключении питания может потеряться много данных.
Хотя на самой ФС все равно какая-то оптимизация нужна, чтобы её внутренние структуры эффективно работали с большим размером кластера.
Ещё и API они поломали, из-за чего старый софт требует изменения исходных кодов для сборки с новым OpenSSL. Работаю с Postgres, привык к 3-й версии PgAdmin'a, а он с новой версией OpenSSL не собирается.
Хорошо, что нашёлся патч для сборки с новым OpenSSL, он довольно большой, несколько сот изменённых строк. То же самое относится и к Qt 4 (хотя я его ставил без патча, просто отключив поддержку OpenSSL, мне она не нужна была).
Это одна из самых противных системных библиотек — часто ломается совместимость старых версий с новыми. Она вызывает больше всего проблем при переносе старых версий ПО на новые системы.
Как-то раз столкнулся с этим, когда файл, зашифрованный openssl'ем на старой системе, не хотел расшифровываться на новой.
В гугле информация о несовместимости версий находится легко по словам вроде "openssl decrypt file encrypted on old version". Сложность в том, чтобы понять, что проблема из-за разницы версий OpenSSL.
Непонятно, зачем нужно требование о том, чтобы данные пользователей из России хранились на серверах в России. Это только из-за желания российских спецслужб иметь возможность получения доступа к ним, а самому пользователю это не нужно, скорее наоборот?
И как тогда быть международным сервисам? Если каждая страна примет такой закон, что данные её пользователей должны в ней находиться, данные российских пользователей должны лежать в России, киргизских — в Киргизии, папуа-новогвинейских — в Папуа-Новой Гвинее, габонских — в Габоне и т.д., сервис должен поставить свои сервера в каждой стране и наладить сложную систему взаимодействия между ними. Если пользователь из одной страны пишет пользователю из другой, то как обеспечить передачу персональных данных пользователя из одной страны в другую? (должен же получатель идентифицировать отправителя, значит, нужно передать ему персональные данные в его страну).
И как определить страну, к которой относится пользователь международного сервиса, если он её явно не указал? по языку? по IP-адресу первичной регистрации? по телефонному номеру? что будет, если он укажет не свою страну, а другую?
Этот лайфхак подойдёт только в том случае, если вам нужен ноутбук для простых задач вроде редактирования текста, и вы готовы смириться с тем, что современные браузеры на них будут тормозить (а просмотр интернета это часто используемая задача). Ещё вариант использования — ставим терминальный сервер и работаем компанией со старых дешёвых ноутбуков в качестве терминалов. Сервер на 10 пользователей и 10 б/у ноутбуков (или старых настольных компьютеров или новых, но очень дешёвых) будут дешевле, чем 10 нормальных компьютеров для работы. И админить проще.
Хотя с Windows могут быть дополнительные затраты на лицензию терминального сервера, но можно считать, что у вас операционная система Linux, работающая в режиме терминального сервера без дополнительных заморочек. Хотя терминалы не должны быть совсем уж старыми, иначе будет тормозить отрисовка.
С совместимостью с современным софтом проблем нет — на быстром компьютере собирается в chroot'e Gentoo 32-битная, переписывается на слабый и современный софт работает, хоть и медленно (браузеры, офис и т.п.). Проблемы могут быть с поддержкой некоторых инструкций процессора (браузерам зачастую нужен хотя бы SSE2), и с малым количеством памяти.
Можно и бинарный дистрибутив поискать, собирающийся под x86, чтобы самому не собирать, но это с годами будет все сложнее. В source based с поддержкой старых архитектур попроще. Можно включить оптимизации, чтобы выжать из дохленького процессора ещё несколько процентов дополнительной производительности.
Я так делал со своим Asus EEE PC 2009 года. Интересно, что в начале прошлого года мне ещё удалось найти под него запчасти (аккумулятор и клавиатуру), и он теперь работает без проблем. В качестве основной машины он не подойдёт. По моим оценкам, он примерно в 50-100 раз слабее нового ноутбука. Если на новом проект собирается 3 минуты, то на маленьком Asus'e он будет собираться около 4 часов. Я не готов ждать так долго!
Но маме для простых игр и что-то глянуть в интернете вполне подойдёт. И ещё долго может подходить.
А как лучше поднять между устройствами беспроводную сеть, если хочется увеличить дальность, а скорость не так важна? Например для разговоров на расстоянии нескольких десятков метров без мобильной сети.
Что лучше для этого подойдёт, Bluetooth или Wi-Fi в каком-то режиме?
Тоже интересовался этим вопросом. Bluetooth гарнитуры работают в двух режимах — A2DP и HSP. Первый режим поддерживает более высокое качество звука, но только в одностороннем режиме (только наушники), второй — более низкое качество, но с микрофоном. Наверное это связано с тем, что Bluetooth гарнитуры рассчитывались под задачи прослушивания музыки (там микрофон не нужен) и под разговоры по телефону (там можно сэкономить на качестве, все равно максимальная частота в телефонной линии 3,4 кГц). А режим качественной записи звука сочли невостребованным и не стали реализовывать, так как он требовал бы от гарнитуры больших затрат энергии на кодирование звука в высоком качестве.
А есть ли в каких-то гарнитурах режим с микрофоном высокого качества?
Интересно, что у меня оказался Wireguard быстрее даже на смартфоне, где он работает в пространстве пользователя.
И адрес клиента в настройках сервера не задаётся, более того, он может меняться во время работы без разрыва соединения. Там задаётся адрес внутри VPN, но он вообще может быть внутренним и никак не выдаёт местоположение пользователя, а также публичный ключ (которого недостаточно, чтобы подключиться от имени клиента, в конфиге которого лежит приватный ключ).
Преимущество OpenVPN в том, что он поддерживает разные способы аутентификации и динамическую выдачу IP-адресов. С Wireguard вам понадобится какой-то свой сервис, который реализует вход пользователя в систему (например, вводом логина и пароля в веб-форму, доступную без VPN по HTTPS), генерит для него конфиг, прописывает туда IP и ключи, добавляет пользователя в конфиг сервера — а в OpenVPN это доступно из коробки. Поменялся IP на стороне пользователя — ему надо поменять конфиг, а OpenVPN просто выдаст новый.
Тогда зачем переживать за диапазон 6 ГГц? Для многоквартирных домов лучше подойдёт стандарт типа WiGig с маломощной точкой в каждой комнате, для загородных домов, где другие точки не мешают, будет хватать и 5 ГГц (может и 2,4 ГГц тоже, если дальность важнее, чем скорость). Для уличных точек из-за бóльшей дальности будет лучше подходить 2,4 ГГц.
Не хочется тянуть кабели в квартире? миритесь с неизбежными физическими ограничениями — если точка доступа пробивает стены, ей будут мешать соседские точки.
Не думаю — скорее всего развитие беспроводных технологий просто упёрлось в нехватку частот. Чем больше скорость передачи, тем больше нужно частотной полосы. Причём увеличивать частоты бесконечно тоже не получается — падает проникающая способность.
Мобильная связь на высокочастотном 5G была бы очень неудобной из-за неустойчивого сигнала. Даже на 4G (1.8 ГГц) это сильно заметно, на даче есть место, где на возвышенности очень хороший сигнал, а в 200 метрах в кустах связь пропадает. На 5G добиться устойчивого покрытия везде было бы гораздо сложнее.
Даже если бы можно было отвести под связь вообще все существующие частоты без ограничений, все равно бы упёрлись, но чуть позже.
WiFi в многоквартирных домах будет работать плохо всегда, если точка доступа будет в каждой квартире, и на 5 ГГц, и на 6. Возможно как-то могло бы помочь взаимодействие между точками доступа в одном доме. Или увеличение частоты до такой степени, чтобы сигнал не проходил сквозь стены, с установкой маломощной точки доступа или излучающего кабеля в каждой комнате.
Это похоже на переносимость телефонных номеров. Без переносимости получается похожая зависимость от окружения: человек хотел бы сменить оператора, но ему приходится пользоваться старым номером, чтобы оставаться в контакте со своим окружением.
Операторам переносимость тоже невыгодна и они не стали бы добавлять её по своей воле. До этого дошло с политической волей государства и общим запросом пользователей на такую функцию.
Почему в случае с мессенджерами должно пойти по-другому, и зависимость от поставщика для поддержания общения должна сохраняться? только потому, что мобильные операторы стоят под государствами, а мессенджеры нет, а пользователям проще поставить ещё одно приложение, чем подключить тариф другого оператора — они же не платят за это деньги, а расходуют только немного трафика и заряда батарейки телефона? Или есть ещё какое-то принципиальное отличие между телефонной сетью, email и мессенджерами с соцсетями, из-за которого первые два способа общения интероперабельны, а последний нет?
Подарок нашим депутатам — только как они заикнулись о цензуре со стороны интернет-гигантов, они им подкинули такой шикарный аргумент, зацензурив самого Трампа по явно политическим причинам.
Но мне кажутся мерзкими обе стороны — и наши с борьбой с цензурой с помощью своей цензуры, и интернет-гиганты, потерявшие даже видимость нейтральности и использующие свои технические возможности для продвижения каких-то политических взглядов (как Google решил заблокировать приложение, используемое сторонниками Трампа).
Мне кажется, что интернет-гигантами должны заняться антимонопольные органы развитых стран. Их приложения образуют разновидность монополии, когда потребитель вынужден использовать их приложение для общения просто потому, что его окружение использует это приложение (например как Whatsapp). Почему чтобы связаться с пользователем Whatsapp или Facebook, мне нужно их приложение? Это ограничивает мою свободу выбора, как потребителя. Я считаю, что мне Whatsapp не нужен, но через него передают какие-то интересующие сведения люди из моего окружения, поэтому я вынужден его использовать. При этом корпорация Facebook может иметь доступ к моим данным и даже пытаться мною манипулировать в каких-то своих целях. Почему нельзя сделать IM или голосовое общение так же, как в электронной почте? где есть независимость от поставщика — у одного почта на Гугле, у другого на Яндексе, у третьего вообще на своём домене, и все они могут связываться друг с другом. А если у одного только Whatsapp, у другого Telegram, у третьего ВК — они уже не смогут друг с другом связаться!
Необходимо добиваться стандартизации для IM и голосового общения, сделав обязательными интерфейсы в виде открытых и стандартных протоколов (например, Jabber для IM или SIP для звонков) для мессенджеров с определённой аудиторией, чтобы пользователям не приходилось ставить определённое приложение только потому, что его знакомые используют его.
В таком случае корпорации не могли бы легко блокировать сторонников Трампа или кого-то ещё, сторонники могли бы просто запустить Jabber сервер на своём домене и продолжить общение там, при достаточной распространённости Jabber по сравнению с Facebook и т.п.
Там был параметр, если мне память не изменяет, -noaccurate_seek, по которому FFmpeg старается сдвинуть начало обрезаемого куска так, чтобы оно на ключевой кадр попадало. Если же нужно точно задать при этом время начала, можно сохранить отдельно часть от начального кадра до следующего ключевого кадра с перекодированием в тот же формат, чтобы кадры перекодировались начиная с ключевого, а потом часть с ключевого кадра без перекодирования, и объединить их.
Да ничего страшного не случится. Операторы для реализации этого предложения введут тариф "социальный" с бесплатным доступом к ограниченному списку сайтов, но с ограничением скорости до 128 кбит/c, чтобы прочитать новости можно было, или оплатить что-то, зайти на госуслуги, передать показания счётчиков, а музыка и видео, а также удобный доступ без ожидания были доступна только платным пользователям. Так, как это делает Yota, где есть бесплатный интернет на очень маленькой скорости 64 кбит/c, но даже без ограничения по сайтам. Смысл этого в том, что ощущение неудобства от пользования таким интернетом стимулирует пользователя перейти на обычный платный тариф. Эти пользователи и оплатят такой бесплатный доступ, тем более из-за низкой скорости он не даст значительной новой нагрузки на сеть.
И ещё один тест. Запустил noVNC, подключался с EEE PC через браузер — производительность нормальная, ничего не тормозит даже на слабом железе! Но нет звука, VNC его не поддерживает.
Для стриминга игр звук всё же желателен. Лучше подумать в этом направлении. На сервере звук можно перенаправить через PulseAudio на прокси, который через webrtc будет отдавать его клиенту. На декод и воспроизведение звука много ресурсов не уйдёт (тем более в ограниченном качестве 8000 Гц — для старых игр этого достаточно).
Ещё для теста запустил Дум с EEE PC на сервере через обычный VNC. Никаких тормозов не наблюдалось, игра запустилась с достаточной скоростью. Может быть, и вам лучше попробовать вместо ffmpeg попробовать использовать VNC или другой подобный протокол с более высокой производительностью? VNC клиенты, работающие через браузер, существуют, Apache Guacamole например.
Потестировал ещё.
На сайте js-dos.com есть аналогичная возможность запустить игры для DOS в браузере через JS. И там даже на EEE PC Дум запустился, хотя шёл с большими тормозами, играть было неудобно. В простые игры типа Тетриса игралось нормально.
Я также попробовал запустить стриминг Дума на нормальном ноутбуке. Игра запускается, ввод обрабатывается, тормозов нет, но иногда неприятно смазывается картинка. Локальный режим лучше.
Интересно, я решил проверить, и у меня игра запустилась на стороне клиента, через эмулятор JSDOS. Я даже пробовал сетевой кабель выключить, и игра продолжала работать.
Правильно я понял, что для игры по описанной в статье схеме нужно использовать турбо-режим? а в обычном игра обсчитывается только на стороне клиента. Я попробовал поиграть в DOOM в обычном режиме и не почувствовал никаких тормозов. Но у меня мощная машина, попробую на слабой.
На слабой (проверял на EEE PC 901) обычный режим не запускается вовсе, зависает на "JSDOS Starting". Турбо-режим запускается, но не реагирует на ввод.
Пробовал на мобильном (среднем samsung galaxy 2018 года) — и в обычном режиме производительности достаточно, чтобы поиграть в DOOM.
Версия браузера на обоих устройствах (нормальном ноутбуке и старом EEE PC) одинаковая (Firefox 84.0.1). Возможно, старенькому EEE PC просто не хватает производительности. Если бы я взял устройство помощнее, чтобы хватало мощности на турбо-режим (на обработку ввода с клавиатуры и декод видео), ему скорее всего хватило бы мощности и на обычный локальный режим.
Мне кажется, что трудно найти вариант использования, при котором стриминг для таких не очень ресурсоёмких задач, как старые игры, имел бы преимущество перед локальным выполнением. Если устройство слишком слабое, то на нём и стриминг не пойдёт комфортно. Если оно достаточно производительное, на нём лучше пойдёт локальный режим. Если среднее — трудно сказать, в зависимости от сетевого подключения и загрузки сервера. Стриминг или терминальный доступ имеет преимущество перед локальным выполнением лишь тогда, когда запускаемая задача требует достаточно высокой производительности, на слабых задачах его преимущества не очевидны.
А если сделать кэш на энергонезависимой памяти? например, RAM памяти с батарейкой или SSD небольшого объёма с небольшим размером блока и большим числом допустимых перезаписей?
тогда мы можем писать на основной диск по настроению (или после заполнения кэша), но при внезапном отключении питания данные не потеряются. И этот процесс будет контролироваться операционной системой (например, если приложение последовательно пишет данные большими блоками, то их можно сразу сохранять на основной диск, а если пишет вразнобой мелкими блоками — как-то объединять их в кэше и потом переписывать на основной диск).
А если взять обычную файловую систему, но увеличить размер кластера (допустим до 1 Мб), чтобы он совпадал с размером блока записи/стирания? если нужно хранить много мелких файлов, чтобы место не пропадало, можно обойтись костылями вроде squashfs на диске одним крупным файлом + overlayfs в памяти, файлы обновляются в памяти, а при фиксации данных на диске squashfs обновляется и данные пишутся этими крупными блоками. Если изменений немного по сравнению с общим размером каталога, лучше записать отдельный squashfs с изменениями вместо того, чтобы обновлять основной.
Реальная система может использовать не костыли со squashfs/overlayfs, а что-то другое, но работающее по такому же принципу, собираются блоки данных из изменённых данных большого размера в памяти, потом пишутся на диск сразу большими блоками. Недостаток — данные долго хранятся в памяти и при отключении питания может потеряться много данных.
Хотя на самой ФС все равно какая-то оптимизация нужна, чтобы её внутренние структуры эффективно работали с большим размером кластера.
Ещё и API они поломали, из-за чего старый софт требует изменения исходных кодов для сборки с новым OpenSSL. Работаю с Postgres, привык к 3-й версии PgAdmin'a, а он с новой версией OpenSSL не собирается.
Хорошо, что нашёлся патч для сборки с новым OpenSSL, он довольно большой, несколько сот изменённых строк. То же самое относится и к Qt 4 (хотя я его ставил без патча, просто отключив поддержку OpenSSL, мне она не нужна была).
Это одна из самых противных системных библиотек — часто ломается совместимость старых версий с новыми. Она вызывает больше всего проблем при переносе старых версий ПО на новые системы.
Как-то раз столкнулся с этим, когда файл, зашифрованный openssl'ем на старой системе, не хотел расшифровываться на новой.
В гугле информация о несовместимости версий находится легко по словам вроде "openssl decrypt file encrypted on old version". Сложность в том, чтобы понять, что проблема из-за разницы версий OpenSSL.
Непонятно, зачем нужно требование о том, чтобы данные пользователей из России хранились на серверах в России. Это только из-за желания российских спецслужб иметь возможность получения доступа к ним, а самому пользователю это не нужно, скорее наоборот?
И как тогда быть международным сервисам? Если каждая страна примет такой закон, что данные её пользователей должны в ней находиться, данные российских пользователей должны лежать в России, киргизских — в Киргизии, папуа-новогвинейских — в Папуа-Новой Гвинее, габонских — в Габоне и т.д., сервис должен поставить свои сервера в каждой стране и наладить сложную систему взаимодействия между ними. Если пользователь из одной страны пишет пользователю из другой, то как обеспечить передачу персональных данных пользователя из одной страны в другую? (должен же получатель идентифицировать отправителя, значит, нужно передать ему персональные данные в его страну).
И как определить страну, к которой относится пользователь международного сервиса, если он её явно не указал? по языку? по IP-адресу первичной регистрации? по телефонному номеру? что будет, если он укажет не свою страну, а другую?
Хотя с Windows могут быть дополнительные затраты на лицензию терминального сервера, но можно считать, что у вас операционная система Linux, работающая в режиме терминального сервера без дополнительных заморочек. Хотя терминалы не должны быть совсем уж старыми, иначе будет тормозить отрисовка.
С совместимостью с современным софтом проблем нет — на быстром компьютере собирается в chroot'e Gentoo 32-битная, переписывается на слабый и современный софт работает, хоть и медленно (браузеры, офис и т.п.). Проблемы могут быть с поддержкой некоторых инструкций процессора (браузерам зачастую нужен хотя бы SSE2), и с малым количеством памяти.
Можно и бинарный дистрибутив поискать, собирающийся под x86, чтобы самому не собирать, но это с годами будет все сложнее. В source based с поддержкой старых архитектур попроще. Можно включить оптимизации, чтобы выжать из дохленького процессора ещё несколько процентов дополнительной производительности.
Я так делал со своим Asus EEE PC 2009 года. Интересно, что в начале прошлого года мне ещё удалось найти под него запчасти (аккумулятор и клавиатуру), и он теперь работает без проблем. В качестве основной машины он не подойдёт. По моим оценкам, он примерно в 50-100 раз слабее нового ноутбука. Если на новом проект собирается 3 минуты, то на маленьком Asus'e он будет собираться около 4 часов. Я не готов ждать так долго!
Но маме для простых игр и что-то глянуть в интернете вполне подойдёт. И ещё долго может подходить.
А как лучше поднять между устройствами беспроводную сеть, если хочется увеличить дальность, а скорость не так важна? Например для разговоров на расстоянии нескольких десятков метров без мобильной сети.
Что лучше для этого подойдёт, Bluetooth или Wi-Fi в каком-то режиме?
Тоже интересовался этим вопросом. Bluetooth гарнитуры работают в двух режимах — A2DP и HSP. Первый режим поддерживает более высокое качество звука, но только в одностороннем режиме (только наушники), второй — более низкое качество, но с микрофоном. Наверное это связано с тем, что Bluetooth гарнитуры рассчитывались под задачи прослушивания музыки (там микрофон не нужен) и под разговоры по телефону (там можно сэкономить на качестве, все равно максимальная частота в телефонной линии 3,4 кГц). А режим качественной записи звука сочли невостребованным и не стали реализовывать, так как он требовал бы от гарнитуры больших затрат энергии на кодирование звука в высоком качестве.
А есть ли в каких-то гарнитурах режим с микрофоном высокого качества?