Исторически сложилось, что у нас все сервера были на фряхе, в том числе высоконагруженные СУБД на Firebird. Когда в линуксе анонсировали какие-то улучшения в I/O, мы протестировали производительность на типичной нагрузке и в линуксе получилось на 10% быстрее, перешли на линукс.
Когда к нам в компанию пришли евангелисты микрософт, поднялся вопрос о переводе СУБД под венду. И что неожиданно — она на наших задачах оказалась на 20% (!!!) быстрее линукса, ещё один переход сделали. Благо, firebird многоплатформенный.
Мой тезис был в том, что сейчас многоядерность в Андроид-приложениях не принесёт пользы.
Да, когда-нибудь оно будет так же хорошо поддерживаться, как сейчас на десктопе.
Порвут на синтетических тестах, которые тупо умножают производительность одного ядра на кол-во ядер.
Но к реальным приложениям это какое имеет отношение?
Такому сканеру не нужно хранить библиотеку. Достаточно хранить равки и сливать их в центр, а там уже возможна обработка не в реал-тайме и динамическое перераспределение ресурсов на те регионы, которым сейчас требуется внимание.
Идея для стартапа: выпускать одежду, которая светится под действием невидимой подсветки 3d-сканера.
Популярна будет у молодёжи, исповедующей идеологию «f*ck the system»
Да, у линейки HTC 2012 года что-то не то со стеклом.
Сравниваю DesireZ 2011-го года и Mozart 2012-го.
Оба небрежно эксплуатируются, на моцарте царапин уже много, зетка как новая.
Хотя на моцарте тоже заявлен gorilla glass
Загоняли, но индусские кодеры здесь не к месту упомянуты.
Раньше было как (у нас)?
Сидит себе разработчик, пилит фичи, фиксит баги. К нему напрямую приходят баг-репорты, он может сразу понять, что исправлнеие — дело одной строчки и моментально исправить.
Теперь же решили «сделать процесс прозрачным». Нагнали 100500 бизнес-аналитиков, тестировщиков, диспетчеров (принимающих заявки), запустили SCRUM. Теперь баги доходят до разработчика через 3 пня-колоды, а сам он не определяет, чем заниматься надо — за него по часам всё расписано.
Поэтому с заключением статьи
>> Возможно, у разработчиков просто нет желания исправлять проблемы?
я не согласен. У разработчиков в современных методах ведения разработки больше нет возможности исправлять что-то :(
У меня с прямыми только негативный опыт: во внутреннем кармане куртки прямой штекер действует как рычаг, расшатывая место соединения. Доходило до того, что разъём отваливался и приходилось неоднократно пропаивать на плате КПК. На телефоне штатная гарнитура с прямым штекером умерла из-за того, что шнур у штекера постоянно сгибается в застёгнутом кармане и один из проводов перетёрся. Купил Г-образную и вот уже год никаких проблем.
Поведение NAT перпендикулярно протоколу (TCP/UDP).
Мой роутер, например, не позволяет делать hole punching — если UDP-пакет приходит в дырку от другого IP, а не с того, с кем первоначально установлено соединение, он отбрасывается. Если же ваш роутер принимает в дырку UDP-пакеты с любого IP, вы уверены, что он не делает то же самое с TCP-пакетами?
1) Ну как бы Microsoft не называл свой продукт «проксифаирволом», а проксирование и firewall — это разные технологии (firewall не модифицирует трафик, он только запрещает/разрешает), нежелательно смешивать их в одну кучу, иначе мы друг друга не поймём
2) Вот оно как. Теперь я понял, почему у меня не upload работал. Дело в том, что https-прокси это фактически socks, т.е. проксирует любой tcp-коннект. Чтобы юзеры не использовали его не по назначению для другого софта, админ запретил все порты для https, кроме 443.
Как ни странно, любой файрвол умеет аутентифицировать не только HTTP, но и FTP. И NTLM везде подерживается для него.
Стоп-стоп. Firewall или Proxy?
Firewall ничего не может аутентифицировать, потому что в трафике ftp-протокола нет аутентифицирующей информации (там логин на удалённый хост).
С заходом на ftp в IE через прокси у меня был такой опыт: можно скачивать, но нельзя закачивать. Браузер кидает в проксю обычный HTTP GET но с ftp-шным url-ом (HFTP)
Следовательно, полноценная работа контент-менеджера с ftp через http-прокси с NTLM-авторизацией невозможна
Любопытно, а если на машине запущено несколько сетевых программ под разными учётками, TMG сможет понять, какой трафик от какой учётки, чтобы применить политики?
Исторически сложилось, что у нас все сервера были на фряхе, в том числе высоконагруженные СУБД на Firebird. Когда в линуксе анонсировали какие-то улучшения в I/O, мы протестировали производительность на типичной нагрузке и в линуксе получилось на 10% быстрее, перешли на линукс.
Когда к нам в компанию пришли евангелисты микрософт, поднялся вопрос о переводе СУБД под венду. И что неожиданно — она на наших задачах оказалась на 20% (!!!) быстрее линукса, ещё один переход сделали. Благо, firebird многоплатформенный.
Да, когда-нибудь оно будет так же хорошо поддерживаться, как сейчас на десктопе.
Но к реальным приложениям это какое имеет отношение?
Популярна будет у молодёжи, исповедующей идеологию «f*ck the system»
А скачивание оттуда этим или этим никак не мониторится
Сравниваю DesireZ 2011-го года и Mozart 2012-го.
Оба небрежно эксплуатируются, на моцарте царапин уже много, зетка как новая.
Хотя на моцарте тоже заявлен gorilla glass
Раньше было как (у нас)?
Сидит себе разработчик, пилит фичи, фиксит баги. К нему напрямую приходят баг-репорты, он может сразу понять, что исправлнеие — дело одной строчки и моментально исправить.
Теперь же решили «сделать процесс прозрачным». Нагнали 100500 бизнес-аналитиков, тестировщиков, диспетчеров (принимающих заявки), запустили SCRUM. Теперь баги доходят до разработчика через 3 пня-колоды, а сам он не определяет, чем заниматься надо — за него по часам всё расписано.
Поэтому с заключением статьи
>> Возможно, у разработчиков просто нет желания исправлять проблемы?
я не согласен. У разработчиков в современных методах ведения разработки больше нет возможности исправлять что-то :(
У меня с прямыми только негативный опыт: во внутреннем кармане куртки прямой штекер действует как рычаг, расшатывая место соединения. Доходило до того, что разъём отваливался и приходилось неоднократно пропаивать на плате КПК. На телефоне штатная гарнитура с прямым штекером умерла из-за того, что шнур у штекера постоянно сгибается в застёгнутом кармане и один из проводов перетёрся. Купил Г-образную и вот уже год никаких проблем.
Прочитайте про типы NAT (Full cone, address restricted и т.п.)
ru.wikipedia.org/wiki/STUN
Поведение NAT перпендикулярно протоколу (TCP/UDP).
Мой роутер, например, не позволяет делать hole punching — если UDP-пакет приходит в дырку от другого IP, а не с того, с кем первоначально установлено соединение, он отбрасывается. Если же ваш роутер принимает в дырку UDP-пакеты с любого IP, вы уверены, что он не делает то же самое с TCP-пакетами?
и вы изобрели TCP с его keep-alive ))
2) Вот оно как. Теперь я понял, почему у меня не upload работал. Дело в том, что https-прокси это фактически socks, т.е. проксирует любой tcp-коннект. Чтобы юзеры не использовали его не по назначению для другого софта, админ запретил все порты для https, кроме 443.
Стоп-стоп. Firewall или Proxy?
Firewall ничего не может аутентифицировать, потому что в трафике ftp-протокола нет аутентифицирующей информации (там логин на удалённый хост).
С заходом на ftp в IE через прокси у меня был такой опыт: можно скачивать, но нельзя закачивать. Браузер кидает в проксю обычный HTTP GET но с ftp-шным url-ом (HFTP)
Следовательно, полноценная работа контент-менеджера с ftp через http-прокси с NTLM-авторизацией невозможна