Теоретически, 64 килобита в секунду — это 8 килобайт в секунду. Но на практике, если удастся добиться средней скорости при простом скачивании 6,5 килобайт в секунду — это уже хорошо. Обычно же скорость при скачивании — около 6 килобайт в секунду. При закачивании с торрентов средняя скорость — от 4,5 до 5,5 килобайт в секунду, что ищутимо при более-менее длительном скачивании.
Подрасту? :)
Дело в том, что в некоторых регионах, отличных от Москвы, зарплаты бывают чуть пониже, чем стоит FB. Flex Builder 3 — программа сыроватая (до сих пор), тормозящая даже на Core 2 Duo (может ему Quad нужен?), практически не защищенная, но стоящая почти 700 $.
Photoshop или Office, например, достойные продукты, и стоят своих денег. Но FB 3 за 2 года практически не изменился, такое ощущение, что его сделали и забыли про него, забыли про оптимизацию, улучшение дизайна, исправление ошибок и т.д. Та же аптана обновляется каждый месяц (автоматически причем!) и она тоже сделана на эклипсе.
Зачем все эти трудности, если у FB 3 и так одна из самых слабых защит? Даже если срок триал-версии подходит к концу, FB как ни в чем не бывало продолжает работать.
Ответа не будет: все процессоры, которые должны выйти осенью, уже анонсированы. И, к тому же, AMD больше занята новыми процами Deneb, новым поколением видеокарт и возможной реконструкцией компании. Чем Athlon 2000+ не ответ? :)
Лараби в первом поколении не переплюнет Нвидиа и АМД, а останется далеко позади. Примерное прогнозируемое потребление первого поколения Лараби — 300 Вт. Под АМД и Нвидиа оптимизированы все игры, под Лараби оптимизаций пока никаких нет, и когда они появятся — неизвестно (это лишняя головная боль разработчикам, а зачем она им?). Единственный вариант для Интел, это помещение Лараби в приставку, но тогда нужно будет устранить все недостатки. К 2012 году, когда выйдут первые приставки нового поколения, АМД и Нвидиа могут уйти далеко вперед (сменятся 3-4 поколения видеокарт), и догнать их будет практически невозможно.
Так что, пока никаких поводов для оптимизма нет. :)
Уважаемый sunnybear, я уже упоминал здесь, что моя статья всего лишь перевод. Причем перевод статьи не о том, как оптимизировать что-то, и называется она в оригинале «CSS Sprites2 — It's Javascript Time», а не, например, «CSS Sprites2 — It's Optimization Time». Большая её часть посвящена реализации техники с помощью jQuery, и автор статьи не настаивает на использовании именно этой JS-библиотеки. А CSS Sprites идет как backend, ему посвящены всего несколько абзацев. Ничто не мешает использовать вместо него data: url в данном случае.
Согласитесь, было бы нехорошо, если бы, например, обсуждения статей о реализации чего-либо на PHP, начинались с коммента «Есть более удачная альтернатива PHP — Python» или «В Ruby on Rails это реализуется парой строк». Начало обсуждения статьи было, на мой взгляд, из той же серии. arestov начал обсуждение именно с какого-то утверждения, приведя в доказательство ссылку на вашу статью. Но он, во-первых, по сути не прочитал мой топик (!!) (если бы он прочитал, то не задал бы некоторых своих вопросов), во-вторых, не понял, что это перевод (и я не автор), и, в-третьих, стал ждать того, что я ему буду что-то объяснять по статье, хотя в ней очень подробно все расписано. Говорить о том, что чувствуешь, только что потратив солидное время на перевод, общаясь с человеком, нормально не прочитавшим статью и задающим вопросы имеющие довольно отдаленное отношение к её сути, думаю не стоит. Но мы с ним уже закрыли этот вопрос в личной переписке.
Оптимизация — это огромная тема (в которой вы очень хорошо разбираетесь, судя по профайлу). Я не занимаюсь вопросами оптимизации, но в той фирме, где я работаю, естественно затрагиваются эти вопросы. У нас, почему-то, бОльшую прибавку в скорости дают оптимизации на сервере, запросов к базе данных и программного кода (Ruby). Разница в скорости по сравнению с неоптимизированным кодом получаются чуть ли не на порядок, и этого вполне хватает. До вопросов оптимизации картинок, Javascript и СSS мы почти никогда не добирались, может из-за того, что не было крупных проектов.
AMD совсем перемудрили с наименованиями своих процессоров. называют 1ГГцовый процессор 2000+ )).
В принципе это все меняет. 1 ГГц обходит 1.6 ГГц. Более высокое потребление нивелируется более экономной платой и более скоростныи видеоядром. Жаль таких нетбуков сейчас нет… (
по оценке PC Mark05, мощность процессора Atom N270 (Intel Atom 1.66 ГГц, ASUS Eee PC 901) оказалась такой же или ниже, чем у Celeron M 353 (Intel Celeron M 900 МГц, ASUS Eee PC 900)! А преимущество обеспечила большая эффективность подсистемы памяти и графического контроллера.
Так что, он побыстрее, но ненамного. И то, не за счет процессора…
К сожалению, не изучаю сейчас английский, мне моих знаний пока хватает, поэтому ничего конкретного не могу вам посоветовать. Но вы посмотрите в этом блоге, я видел несколько ссылок.
Да я и сам не прочь с кем-нибудь пообщаться, но скорость интернета пока не позволяет. :) Без интернета и компьютера учить английский было намного сложнее, ту же газету (или, тем более, книгу) достать было проблемой. Сейчас ничего не мешает выучить английский не выходя из дома. По скайпу можно пообщаться с кем хочешь, есть куча сайтов в помощь изучающим, книги, газеты, все к вашим услугам по цене интернета. Было бы время…
Можно конечно пользоваться и урезанной версией за 249$.
Дело в том, что в некоторых регионах, отличных от Москвы, зарплаты бывают чуть пониже, чем стоит FB. Flex Builder 3 — программа сыроватая (до сих пор), тормозящая даже на Core 2 Duo (может ему Quad нужен?), практически не защищенная, но стоящая почти 700 $.
Photoshop или Office, например, достойные продукты, и стоят своих денег. Но FB 3 за 2 года практически не изменился, такое ощущение, что его сделали и забыли про него, забыли про оптимизацию, улучшение дизайна, исправление ошибок и т.д. Та же аптана обновляется каждый месяц (автоматически причем!) и она тоже сделана на эклипсе.
кстати, за последние полгода уже все дни окрашивались в черный цвет, пора уже привыкать… )
Так что, пока никаких поводов для оптимизма нет. :)
Согласитесь, было бы нехорошо, если бы, например, обсуждения статей о реализации чего-либо на PHP, начинались с коммента «Есть более удачная альтернатива PHP — Python» или «В Ruby on Rails это реализуется парой строк». Начало обсуждения статьи было, на мой взгляд, из той же серии. arestov начал обсуждение именно с какого-то утверждения, приведя в доказательство ссылку на вашу статью. Но он, во-первых, по сути не прочитал мой топик (!!) (если бы он прочитал, то не задал бы некоторых своих вопросов), во-вторых, не понял, что это перевод (и я не автор), и, в-третьих, стал ждать того, что я ему буду что-то объяснять по статье, хотя в ней очень подробно все расписано. Говорить о том, что чувствуешь, только что потратив солидное время на перевод, общаясь с человеком, нормально не прочитавшим статью и задающим вопросы имеющие довольно отдаленное отношение к её сути, думаю не стоит. Но мы с ним уже закрыли этот вопрос в личной переписке.
Оптимизация — это огромная тема (в которой вы очень хорошо разбираетесь, судя по профайлу). Я не занимаюсь вопросами оптимизации, но в той фирме, где я работаю, естественно затрагиваются эти вопросы. У нас, почему-то, бОльшую прибавку в скорости дают оптимизации на сервере, запросов к базе данных и программного кода (Ruby). Разница в скорости по сравнению с неоптимизированным кодом получаются чуть ли не на порядок, и этого вполне хватает. До вопросов оптимизации картинок, Javascript и СSS мы почти никогда не добирались, может из-за того, что не было крупных проектов.
В принципе это все меняет. 1 ГГц обходит 1.6 ГГц. Более высокое потребление нивелируется более экономной платой и более скоростныи видеоядром. Жаль таких нетбуков сейчас нет… (
А Intel Atom 1.6 ГГц проигрывает даже Via Nano 1.8 ГГц процентов 20%.
Вы можете ссылку прислать с подтверждением?
Так что, он побыстрее, но ненамного. И то, не за счет процессора…