Собственно английскую и читал. Wimax отнесен к pre-4G, и это скорее из-за временных рамок. По-сути, технологии используемые в LTE схожи с Wimax'овскими, для кодирования данных используются те же QPSK, QAM16, QAM64 и т.д. Наверняка разный формат фреймов (бурстов), ну и разная частотная полоса. Однако Wimax то же по стандарту может работать на совершенно разных частотах.
Я просто о том, что по-сути железная база у них очень схожа (что и писалось выше habrahabr.ru/blogs/hardware/46514/#comment_1187057) и даже чип, над которым мы работаем, может быть адаптирован к LTE, как в своей время к Wibro. И что LG Америку тут со своим «уникальным» чипом не открыл :)
С Вики «picoChip and Mimoon demonstrated a base station reference design. This runs on a common hardware platform (multi-mode / software defined radio) with their WiMAX architecture»
Что в общем, и требовалось доказать. По-сути одна и та же платформа, разница в firmware. Плюс LTE все-таки UMTS based, т.е. использует SIM-Card аутентификацию и насколько я понял, так же как и HSDPA — роуминг GSM сетей.
Совершенно не понятно, чем этот стандарт отличается от Wimax. Нигде не нашел информации о том, какие методы модуляции частот применяются (на вики — OFDMA для dl, как и у Wimax). Далее там аж 4 (!) MIMO антенны. В большинстве современных BS мобильного Wimax — 2 (1 — ul/dl, и еще одна — dl). Вполне вероятно, еще одна вариация на тему Wimax, как в свое время была Wibro.
Достаточно интересно. Несколько Asus, сколько новостей стоит ждать от SE, все-таки на рынке консьюмерских ТЕЛЕФОНОВ, они впереди Asus и Toshiba.
PS Как же мне надоели эти двойные стандарты на хабре. Помнится за копипаст даже банили. Также угрожали банами за кросспостинг. И вот опять 25… Хабр превращается в клон двайса (я конечно понимаю, что речь о взаимовыгодном сотрудничестве, но все же)…
То ли плохая статья, то ли плохой перевод, то ли мешает понять статью — отсутствие экономического образование. Я понял только то, что ценные бумаги, подкрепленные золотом теряют ценность. И наблюдается дефицит реального золота. И как этот процесс увязать в приходом второй великой депрессии?
Вы видимо мало знаете о коммерческой разработке, или мало задумываетесь над последствиями.
Проведем параллель: я считаю, что конвейерная сборка автомобилей — это плохо. Ведь автомат не старается затягивать каждый болтик, не делает это с любовью, не заботится о том, туго ли нажимается педаль газа. А вот ручная сборка — это да, это отлично.
Так вот, вы знаете во сколько раз дороже стоит автомобиль ручной сборки? Вы готовы за это платить?
Так вот, а готовы ли вы платить за такой вот софт, который и летает, и не использует тежялых фреймворков, потому долго и упорно отлаживался?
Я считаю, что дешевле раз в год-два, тратить 800 у.е. на новый компьютер, чем покупать программы по 100-200 баксов вместо 20.
Есть безусловно и очень хорошо отлаженные и отточенные до мелочей продукты, но их единицы… И делается это лишь потому, что подобные продукты преследуют иные цели, и для них этот подход очень выгоден. К примеру приставки… Дешевле вывести одно поколение в 5 лет, и девелопить, оптимизируя каждый байт, нежели раз в год выпускать приставку и убеждать пользователей, что это им нужно (для примера смотрите на приставки Nintendo, после мегадрайва).
Я все понимаю. Но иногда для того, чтобы сделать шаг вперед, иногда в производительности. приходится делать два шага назад. Все потому, что это дешевле!
Юзабилити конечно в первую очередь, но поверьте, найдутся тысячи причин, почему программа тормозит. Программы на Qt могут тормозить не потому, что Qt тормоз, или на каждую мелочь существуют по экземпляру класса, а потому разработчик недоработал.
Я тоже программист, и для меня писать быстрый и стабильный код — очень важно, потому как я пишу драйвера. И тут три требования: загрузка процессора, пропускная способность (сетевые драйвера). Иногда, для того, чтобы достичь более высоких показателей приходится одним из показателей немного пожертвовать. Иногда из-за того, что нужно было сделать еще вчера, приходится использовать воркараунды, или принимать другие непопулярные решения.
Касательно коммерческой разработки: сроки всегда достаточно жесткие, и заказчик всегда заинтересован в том, чтобы сделать как можно дешевле и быстрее. Потому большие и громоздкие фреймворки — тут в фаворитах. Это бич всех аутсорсинговых проектов. Но посмотрите на это с другой стороны. Когда бы появился аналог Vista, если бы до сих пор продолжали писать на ассемблере?
Касательно своих проектов… Я всегда стараюсь использовать то, на чем мне удобно писать, и где изобретение велосипедов сокращенно до минимума.
Скажите, вы программист? Мышление и суждения у вас далеки от программистских. Хром очень тормозит, когда открыто много вкладок. А если вы долго не открывали вкладку, и ее содержимое уже давно ушло в своп, то будет всплеск дисковой активности и пиковая нагрузка на процессор прыгнет до неимоверных высот.
Это разная идеология построения десктопных приложений. FF и Opera подгружают по максимуму компонентов сразу. Хром распределяет эту нагрузку и грузит все что-нужно по мере необходимости. Однако представьте себе фотошоп, который стартовал бы мгновенно, а подгружал плагины по мере необходимости. Вы бы уже вспомнили матерей всех разработчиков. Иногда сплеш — это необходимость.
«Он делает легкой и беззаботной жизнь кодера, но пользователь за это расплачивается, и необходимостью покурпать железо»
От этого никуда не уйти. Статическая html страница тоже будет грузится быстрее, нежели страница сгенерированая php скриптом. Разрастаются фреймворки, увеличиваются требования к железу, но и возможностей становится больше.
Если вам нужна утилита, которая собирает минимум данных и рендерит их на экран — используйте WinAPI. Не стоит забивать гвозки кувалдой, если можно взять молоток. Qt же в свою очередь — фреймворк не на все случаи жизни, веб портал на нем не напишешь :)
.NET — Windows Only, мало кто связку Qt + Mono пустит в продакшн для других ОС. Java — да, но пардон, она под Linux и Mac OS использует GTK, что очень ограничивает возможности. Да и перфоманс пенальти есть небольшой.
При зарплатах программистов в 2К даже у нас, один раз потратится на лицензию — не проблема.
Не воспринимайте мою реплику, как камень в огород Qt. Мне нравится писать на Qt, просто есть в нем одни грабли, на которые наступают начинающие разработчики со своим проектом. Затем когда проект разрастается и становится популярным — эти грабли остаются на месте, а потом у людей складывается впечатление, что Qt — тормоз
Слушайте, а вот что вы можете предложить, вот честно? :) Qt на то и библиотека, чтобы быть громоздкой. Ведь она содержит миллионы действий, которые вы с помощью WinAPI будете изобретать один, два дня, вместо того, чтобы создать экземпляр класса и вызвать метод.
И таким вот ресурсным оверхедом обладает любой фреймворк, в большей или меньшей мере. При желании ведь Qt можно урезать для своих нужд. Ну и использовать динамическую линковку.
А смысл, это ведь по-сути как раз костыль? Хотя доля правды в этих словах есть: обработчики не стоит шибко насиловать.
Проблема QT в том, что она навязывает определенную парадигму программирования: сигнал слот. И разработчики любят ею злоупотреблять, потому что это удобно! В итоге программа становится однопоточной, обработчики событий перегруженными, и страдает перерисовка окна и обработка событий от пользователя. qutIM очень этим страдает. Хотял для начала с этим бороться, но потом забил.
Я просто о том, что по-сути железная база у них очень схожа (что и писалось выше habrahabr.ru/blogs/hardware/46514/#comment_1187057) и даже чип, над которым мы работаем, может быть адаптирован к LTE, как в своей время к Wibro. И что LG Америку тут со своим «уникальным» чипом не открыл :)
Что в общем, и требовалось доказать. По-сути одна и та же платформа, разница в firmware. Плюс LTE все-таки UMTS based, т.е. использует SIM-Card аутентификацию и насколько я понял, так же как и HSDPA — роуминг GSM сетей.
PS Как же мне надоели эти двойные стандарты на хабре. Помнится за копипаст даже банили. Также угрожали банами за кросспостинг. И вот опять 25… Хабр превращается в клон двайса (я конечно понимаю, что речь о взаимовыгодном сотрудничестве, но все же)…
Проведем параллель: я считаю, что конвейерная сборка автомобилей — это плохо. Ведь автомат не старается затягивать каждый болтик, не делает это с любовью, не заботится о том, туго ли нажимается педаль газа. А вот ручная сборка — это да, это отлично.
Так вот, вы знаете во сколько раз дороже стоит автомобиль ручной сборки? Вы готовы за это платить?
Так вот, а готовы ли вы платить за такой вот софт, который и летает, и не использует тежялых фреймворков, потому долго и упорно отлаживался?
Я считаю, что дешевле раз в год-два, тратить 800 у.е. на новый компьютер, чем покупать программы по 100-200 баксов вместо 20.
Есть безусловно и очень хорошо отлаженные и отточенные до мелочей продукты, но их единицы… И делается это лишь потому, что подобные продукты преследуют иные цели, и для них этот подход очень выгоден. К примеру приставки… Дешевле вывести одно поколение в 5 лет, и девелопить, оптимизируя каждый байт, нежели раз в год выпускать приставку и убеждать пользователей, что это им нужно (для примера смотрите на приставки Nintendo, после мегадрайва).
Юзабилити конечно в первую очередь, но поверьте, найдутся тысячи причин, почему программа тормозит. Программы на Qt могут тормозить не потому, что Qt тормоз, или на каждую мелочь существуют по экземпляру класса, а потому разработчик недоработал.
Касательно коммерческой разработки: сроки всегда достаточно жесткие, и заказчик всегда заинтересован в том, чтобы сделать как можно дешевле и быстрее. Потому большие и громоздкие фреймворки — тут в фаворитах. Это бич всех аутсорсинговых проектов. Но посмотрите на это с другой стороны. Когда бы появился аналог Vista, если бы до сих пор продолжали писать на ассемблере?
Касательно своих проектов… Я всегда стараюсь использовать то, на чем мне удобно писать, и где изобретение велосипедов сокращенно до минимума.
Это разная идеология построения десктопных приложений. FF и Opera подгружают по максимуму компонентов сразу. Хром распределяет эту нагрузку и грузит все что-нужно по мере необходимости. Однако представьте себе фотошоп, который стартовал бы мгновенно, а подгружал плагины по мере необходимости. Вы бы уже вспомнили матерей всех разработчиков. Иногда сплеш — это необходимость.
От этого никуда не уйти. Статическая html страница тоже будет грузится быстрее, нежели страница сгенерированая php скриптом. Разрастаются фреймворки, увеличиваются требования к железу, но и возможностей становится больше.
Если вам нужна утилита, которая собирает минимум данных и рендерит их на экран — используйте WinAPI. Не стоит забивать гвозки кувалдой, если можно взять молоток. Qt же в свою очередь — фреймворк не на все случаи жизни, веб портал на нем не напишешь :)
При зарплатах программистов в 2К даже у нас, один раз потратится на лицензию — не проблема.
И таким вот ресурсным оверхедом обладает любой фреймворк, в большей или меньшей мере. При желании ведь Qt можно урезать для своих нужд. Ну и использовать динамическую линковку.
Проблема QT в том, что она навязывает определенную парадигму программирования: сигнал слот. И разработчики любят ею злоупотреблять, потому что это удобно! В итоге программа становится однопоточной, обработчики событий перегруженными, и страдает перерисовка окна и обработка событий от пользователя. qutIM очень этим страдает. Хотял для начала с этим бороться, но потом забил.