Подарок нашим депутатам — только как они заикнулись о цензуре со стороны интернет-гигантов, они им подкинули такой шикарный аргумент, зацензурив самого Трампа по явно политическим причинам.
Но мне кажутся мерзкими обе стороны — и наши с борьбой с цензурой с помощью своей цензуры, и интернет-гиганты, потерявшие даже видимость нейтральности и использующие свои технические возможности для продвижения каких-то политических взглядов (как 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 кГц). А режим качественной записи звука сочли невостребованным и не стали реализовывать, так как он требовал бы от гарнитуры больших затрат энергии на кодирование звука в высоком качестве.
А есть ли в каких-то гарнитурах режим с микрофоном высокого качества?
У WiFi, особенно в сложных условиях (2,4 ГГц в многоквартирных домах) проблемы со стабильностью связи, часто встречаются небольшие затыки, поэтому для требовательных к задержкам приложений (игры, IP-телефония) он не подходит.
А есть ли в современном WiFi оптимизация не для увеличения скорости, а для повышения стабильности или дальности? чтобы поставил на даче точку доступа, и на расстоянии 100-200 метров можно было разговаривать с неё по телефону? скорость большая для этого не важна, а помехоустойчивость желательна.
А почему с современным софтом на 4-м пне без шансов? у браузеров в требованиях к процессору есть только sse2, а он уже в pentium 4 есть. Есть до сих пор дистрибутивы Linux, поддерживающие 32-битную архитектуру. В любом случае можно запустить на современной машине в chroot 32-битную Gentoo, поставить march=pentium4 или prescott, и ставить туда что угодно, а потом переписывать на старый. Современный веб будет притормаживать, но для простых задач вроде работы в офисных приложениях и простых игр такой компьютер до сих пор сгодится. Скорее производительность упрётся в объём RAM, чем в процессор.
А с IPv6 будет работать?
Как я понимаю, нужен prefix delegation с более крупным префиксом, чем /64, чтобы побить его на /64 для каждого VLAN'a. Не все провайдеры дают такую возможность.
Один /64 теоретически можно разделить, но тогда не будет работать автоконфигурация, только статические адреса, что неудобно. В андроиде я вообще не нашёл задания статических IPv6 адресов, только IPv4.
Подарок нашим депутатам — только как они заикнулись о цензуре со стороны интернет-гигантов, они им подкинули такой шикарный аргумент, зацензурив самого Трампа по явно политическим причинам.
Но мне кажутся мерзкими обе стороны — и наши с борьбой с цензурой с помощью своей цензуры, и интернет-гиганты, потерявшие даже видимость нейтральности и использующие свои технические возможности для продвижения каких-то политических взглядов (как 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 кГц). А режим качественной записи звука сочли невостребованным и не стали реализовывать, так как он требовал бы от гарнитуры больших затрат энергии на кодирование звука в высоком качестве.
А есть ли в каких-то гарнитурах режим с микрофоном высокого качества?
У WiFi, особенно в сложных условиях (2,4 ГГц в многоквартирных домах) проблемы со стабильностью связи, часто встречаются небольшие затыки, поэтому для требовательных к задержкам приложений (игры, IP-телефония) он не подходит.
А есть ли в современном WiFi оптимизация не для увеличения скорости, а для повышения стабильности или дальности? чтобы поставил на даче точку доступа, и на расстоянии 100-200 метров можно было разговаривать с неё по телефону? скорость большая для этого не важна, а помехоустойчивость желательна.
Ирине Яровой на радость. Для её сценария использования (раз записали и маловероятно, что потом прочитаем) лента подходит лучше всего.
А почему с современным софтом на 4-м пне без шансов? у браузеров в требованиях к процессору есть только sse2, а он уже в pentium 4 есть. Есть до сих пор дистрибутивы Linux, поддерживающие 32-битную архитектуру. В любом случае можно запустить на современной машине в chroot 32-битную Gentoo, поставить march=pentium4 или prescott, и ставить туда что угодно, а потом переписывать на старый. Современный веб будет притормаживать, но для простых задач вроде работы в офисных приложениях и простых игр такой компьютер до сих пор сгодится. Скорее производительность упрётся в объём RAM, чем в процессор.
А с IPv6 будет работать?
Как я понимаю, нужен prefix delegation с более крупным префиксом, чем /64, чтобы побить его на /64 для каждого VLAN'a. Не все провайдеры дают такую возможность.
Один /64 теоретически можно разделить, но тогда не будет работать автоконфигурация, только статические адреса, что неудобно. В андроиде я вообще не нашёл задания статических IPv6 адресов, только IPv4.