Ну почему же — почту читать, в IM сидеть и по сайтам (не видео) ходить можно и на 64 кбит/с после превышения 5мб ограничения.
И с безлимитом, по крайней мере не случится такого, что какое-то обновление на телефоне/ПК везапно потратит драгоценный трафик.
Ну да, поставить расширение.
Если проблемы с opera и chrome не будут решены — так и сделаю.
Я Firefox давно не использовал, а greasemonkey — вообще никогда. Просто есть подозрение, что функциональность, реализованная в браузере авторами — надёжнее, чем расширение, написанное неизвестно кем.
Балансировка мне не нужна (т.к. по ipv6 скорость не ограничена, и всё, требующее скорости гоняем через ipv6), да и, боюсь, сложновато это будет.
> MAC у проводной и wi-fi сети разные
Знаю, сейчас обходим это, сделав на каждом компьютере у wi-fi тот же mac, что и у проводной карты. Если не включать одновременно провод и wifi — то работает. (кстати не пойму, как iptables могли бы решить это проблему?)
> 1 способ
Это как раз то, что я и планировал, хотелось бы уточнить на какой прошивке и как это реализовать. Предположу, что в OpenWRT все эти функции есть, раз вы её упомянули? Настройка через WebUI или через консоль?
> Делаем два SSIDа
Они будут занимать один канал, или два?
> мобильные устройства роутерятся роутером через его канал.
Как настроить, чтобы при этом на мобильных работал и ipv6? Либо роутер должен выдавать им адреса, либо он должен передавать через себя Router Advertisement-ы от вышестоящих роутеров.
Насчёт вашего решения:
1) Покупать свитч — пусть и не большие, но деньги. Лишнее устройство, лишний кабель питания к нему тянуть.
2) Возможно я не вполне ясно объяснил, но стационарные компьютеры должны тоже иметь возможность подключаться через Wi-Fi. Они стационарные только в том смысле, что это местные жители. Но по форм-фактору — это ноутбуки, которые перемещаются по комнате и не всегда подключены через Ethernet.
3) «клиенты за роутером — за NATом» — как при этом будет работать ipv6 на клиентах за роутером? Да, мультикаст нужен только на стационарных
Первый пример — с дисплеем. Можно подумать, что просто слабое железо, поэтому игры тормозят. А можно зайти на форум, прочитать что это баг тачскрина, скачать патч и т.д.
Второй пример — «невозможность принять звонок при активном GPRS». Этого можно вообще не замечать долгое время, если случайно кто-то не скажет, или если не прочитать где-то о нём и не проверить. А между тем возможность принимать звонки — это ОСНОВНАЯ функция телефона, как можно говорить о качестве, если основная функция не работоспособна?
К слову у вас эта проблема с невозможностью позвонить на аппарат при работе в интернет через 2G проявляется? (тыц)
В 3G вроде пишут что ОК, но 3G быстрее батарею садит.
А вот когда баг исправляют (например с экраном). Эти исправления багов приходят автоматически как сервис паки в, к примеру, Windows?
Или нужно идти в СЦ, чтобы перепрошили? Или предлагается скачивать новые официальные прошивки с сайта производителя?
sizeof(int) == 4, g++, Linux vds0 2.6.34-12-xen #1 SMP 2010-06-29 02:39:08 +0200 i686 GNU/Linux
дома (Windows, MSVC++, тоже 32 бит) ответ 0 0 0 0
Оба компилятора ругаются, на "<<32":
g++: warning: left shift count >= width of type
MSVC++: warning C4293: <<: отрицательное или слишком большое смещение; поведение не определено
Шифрованный контейнер — это НЕ хэш функция, в нём НЕТ лавинного эффекта.
Шифрование блочное, при изменении файлов внутри контейнера изменятся ТОЛЬКО затронутые блоки.
Простейшая иллюстрация: если бы было верно, что «контейнер сильно меняется даже при незначительном изменении файлов внутри контейнера», то при изменении любого файла в большом контейнере — весь контейнер бы изменялся и записывался заново на диск. Сколько бы тогда диск прослужил? Сколько бы времени занимало сохранение любого файла?
Оверхед будет, не спорю. Но потрачено будет всё равно c * (n + b) трафика, где:
b — максимум из размеров блока дропбокса и трукрипта (около сотни килобайт)
c — затраты на пересылку неизменённых частей блоков (зависит от степени фрагментации фс в контейнере, думаю не больше 2, но скорее около 1)
n — объём изменённых данных
"&" в конце, чтобы шелл не ждал завершения работы скрипта
перенеправление потока вывода и ошибок в /dev/null — чтобы скрипт при попытке вывести в stdout или stderr какой-то текст не вывалился с ошибкой (без перенаправления дескриптор будет недействителен, т.к. консоль скрипту будет после дисконнекта недоступна)
Можно вместо /dev/null перенаправить в файл, если есть необходимость видеть вывод скрипта.
И с безлимитом, по крайней мере не случится такого, что какое-то обновление на телефоне/ПК везапно потратит драгоценный трафик.