Редактор Habrahabr, Geektimes
0,0
рейтинг
4 июня 2014 в 12:44

Разработка → Google выпустил 64-битную версию Chrome для Windows



Вчера Google анонсировал 64-битную версию своего браузера Chrome. Для того, чтобы получить эту версию, необходимо выбрать либо Dev Channel либо Canary channel, для пользователей Windows 7 и 8.

Надо думать, что 64-битные билды браузера через время перейдут в стадию бета, а затем получат и stable-версию.

По словам разработчиков, новая версия Chrome на 25% производительнее обычной версии. Кроме того, браузер поддерживает некоторые «плюшки» Windows 8, например High Entropy ASLR, что делает браузер немного более безопасным.

Также разработчики утверждают, что 64-битная версия браузера более стабильна, чем 32-битная. Вроде как «падает» браузер на 50% реже, чем 32-битная версия. В общем, теперь слово за пользователями, опробовавшими новый билд Chrome.

Via chromium
marks @marks
карма
170,2
рейтинг 0,0
Редактор Habrahabr, Geektimes
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (104)

  • –10
    А обновить текущий нельзя до 64-битной?
    • +1
      Даже если на Dev Channel, то надо заново качать.
    • +2
      Ставите новый, он подтягивает ваш профиль и прочее. Какое обновление вы имеете ввиду?
      • +1
        Да, это и имелось. Не потрется ли профиль.
        • +2
          Накатил дев, он заменил основную версию и она стала x64 ничего не потеряв.
      • 0
        Так настройки плагунов то он не поддтянет
        • 0
          Это целиком и полностью зависит от автора плагина. Реализовать такую возможность можно, но не все это делают
  • +14
    В заголовке нужно явно указать, что это для ОС Windows. А то я уже было испугался…

    $ file /opt/google/chrome/chrome
    
    /opt/google/chrome/chrome: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x86b11e2c8d00caf4b88067a7ba0391ebd460d525, stripped
    • 0
      Действительно. Исправил заголовок, спасибо.
  • +18
    Ну а что с 64-битной версией под макось?
    • +29
      Пожалуйста, поясните, за что минусуете. Я уже давно жду 64-битную версию под Mac OS. Это важно из-за невозможности обновить Java, которая доступна только в 64-битной версии.
      • +21
        Это хабр, им лишь бы заминусить
      • 0
        А объясните мне, идиоту, что у вас за проблемы с Java? Она к концу года в Chrome перестанет работать всё равно, так какая вам разница — произойдёт это сейчас или чуть позже?
  • +112
    Это для того, чтобы он мог отожрать ещё больше памяти?
    • +21
      Вы оказались правы. Поставил х64 версию, запустил вкладку с Gmail, откушал ~500 Мб. Переставил обычный хром ~256 Мб.
      • +9
        Я очень люблю хром, но эта фраза была первой моей мыслью просле прочтения заголовка)
        • +33
          640 гигабайт памяти хватит всем!
          • +65
            Кроме хрома, конечно же
      • 0
        +1 с одной открытой вкладкой ~450 Мб…
    • +3
      Не знаю как для вас, но у меня давно больше претензий к софту не в плане потребления памяти, а в плане производительности. Тот же Firefox на двух Core2Duo компах тормозит страшенно (кстати не стесняясь при этом кушать полтора гига оперы).

      Да пусть жрёт хоть 2, хоть 3 гига, лишь бы летал (как хром).
      • 0
        2...3, эх, у меня он почему то отжирает ВСЮ память (её правда всего 8 :) ), и при этом, мало того, что начинает тупить сам, так тупит ещё и всё остальное, включая ОС и остальные приложения. Приходится с интервалом в несколько часов в диспетчере задач хрома убивать все вкладки, а раз в сутки перезапускать его целиком, ибо 2-3 ГБ начинает занимать только хром с одной «пустой» вкладкой.
    • 0
      Вчера поставил себе. На моем слабеньком компе такое ощущение, что только для браузера оперативка существует.
  • –3
    Наконец-то мне под маком для интернет-банка с его «только-64-бит-явой» не придётся ходить в другой браузер…
    • 0
      Промсвязьбанк? их клиент работает в хроме
      • 0
        Авангард. Работает-то работает, а вот когда надо документы подписать, приходится в фаерфокс ходить.

        • 0
          Вот, вот, именно для него держу отдельный файрфокс, больше мне java нигде не нужна.
  • +1
    Для OS X качнул:

    $ file /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome
    /Applications/Google Chrome.app/Contents/MacOS/Google Chrome: Mach-O executable i386

    $ file /Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary
    /Applications/Google Chrome Canary.app/Contents/MacOS/Google Chrome Canary: Mach-O executable i386

    Я думал он давно 64-битный :(
  • +5
    Это круто, конечно, но зачем? Чтобы браузер мог теперь съесть всю оперативку?
    Или там какая-то хитрая ассемблерная оптимизация V8?
    • +5
      Во-первых, 64-битный код при должной оптимизации быстрее. Во-вторых, это позволяет создать полностью 64-битное окружение. Начертей держать в ОЗУ второй комплект DLL?
      Не говоря уже о том, что новых 32-битных систем на Windows уже не нет.
      • +22
        этот второй комплект DLL в озу в разы меньше, чем то, что кушает браузер :D
        • 0
          Странная логика. И чего? Давайте жить на 32 битах?
          И, кстати, метров 400 минимум 32-битная подсистема отъедает.
          • +11
            ну я живу на 64 битах давно.
            а в случае винды — да, давайте жить на 32 битах. потому что эти 400 метров на все приложения лучше, чем по 500-600 метров лишнего на каждом.
          • 0
            Не обязательно. Конечно, родное х64 лучше. Но говорить о 25% увеличении производительности… ну это то же самое, что сказать, что на оптимизацию х86 версии мы тупо забили и не смогли.
            • +1
              неверно. 64битное приложение при одинаковом уровне оптимизации всегда будет быстрее. одна из причин — большее число доступных регистров процессора (и большая разрядность, что менее важно).
      • 0
        >> новых 32-битных систем на Windows уже не нет

        На восьмидюймовых виндовых планшетах обычно 32-битная винда.
    • 0
      Единственная реально полезная фича перехода на 64 бита это увеличение безопасности (почитайте про различия в механизмах защиты для 32х и 64х битных версий приложений). Что же касается производительности, то гораздо больший прирост можно достичь за счёт векторизации (наборы SSE, AVX). По поводу оперативки Хром и сейчас уже имеет паскудную архитектуру, которая просто выжирает ресурсы, одна только невозможность запретить автоматом загружать фоновые вкладки чего стоит, в том же FF гораздо лучше, более того FF уже штатно учат полностью выгружать долго не используемые вкладки из памяти, и освобождать все ресурсы, хотя и сейчас это для FF можно сделать сторонним плагином. Для Хрома выгрузку, и запрет загрузки даже с помощью плагина нормально не сделаешь, ибо начинается загаживание истории псевдо ссылками от расширения, и т.п. косяки, а всё потому что нормально апи для работы с вкладками в Хроме нет.
      • 0
        Настоящим же апофигеем абсурда является тот факт, что весь код, который нужен для автоматической выгрузки/подгрузки закладок в Chrome уже есть (он используется на Android'е и ChromeOS).
        • 0
          Это факт, и это… а, впрочем, смысла материть кого либо всё равно нет.
  • –4
    «Немного более безопасным».
    Больше лучше одеваться, ей-богу.
    • –1
      Та ну, это какая-то болезнь. КНТВМ, «Света из Иванова» будет первой на очереди в реактор, учитывая отягчающие обстоятельства — коверканье родного языка.
      • –1
        Вообще-то, я имел в виду, что это абсолютный маразм, так писать.
        Не понимаю агра, на самом деле.
  • +11
    Интересно, улучшение стабильности на 50% как-то связано с тем, что 32 — это 50% от 64?) Хотя в таком случае это на 200%, а не на 50%
    • +7
      — I have 32-bit Windows 7. I need 64 bit to game. How to get 64 bit? Will I get it if install twice?
      — Yes install twice. You’ll also get Windows 14.
    • 0
      Улучшение стабильности ИМХО связано с тем, что они вынужденны были провести ревизию и рефакторинг кода, который для 64х бит мог начать криво работать, и переписали эти биоразложимые участки по нормальному :)
      • 0
        Они сравнивают с той же самой версией Chrome, собранной из тех же самых исходников, так что — мимо.
        • 0
          Да, мимо, однако это всё равно приводит меня к той же причине — не переносимый или кривоватый код, который по разному работает в зависимости от внешних условиях… хотя, может у них 32 битная версия падала просто от того, что на одну страничку не хватало 2 ГБ, в таком улучшении стабильности я вообще не сомневаюсь, ибо часто такое у себя наблюдаю, особенно на сайтах с «бесконечной» разметкой :)
  • –1
    Вот скажите мне, кто заметил разницу при использовании 64-бит по сравнению с 32?
    • НЛО прилетело и опубликовало эту надпись здесь
      • +1
        Не хочу, просто хочу понять смысл всех заморочек если это никак не влияет на конечный результат.
        • 0
          Смысл прост. Если улучшение не видно на глазок, это не значит, что это никак не влияет на конечный результат. Если результат нужен сию секунду, то может улучшением и можно пренебречь, но нужно же смотреть в будущее :-)

          Лучше улучшать маленькими итерациями, чем никак…

          habrahabr.ru/company/host-tracker/blog/224431/
      • 0
        Честно говоря, я первым делом провел тест 64-битного на Peacekeeper. Он выдал на моем железе 4663 попугая.
        Для сравнения: когда я только купил себе комп, уйдя с ноутбука на стационарник, я решил проверить как новое железо повлияло на производительность браузера. Тогда у меня стоял Chrome 34.0.1847.92, 32 бита естественно. Выдало это чудо 5527 очков.
        Это уже не на глазок, но не обнадеживает.
  • –8
    Как то жалко пользователей стало. Неужели совсем всё так плохо?
  • +1
    По словам разработчиков, новая версия Chrome на 25% производительнее обычной версии. Мне кажется Хром скоро будет загружаться быстрее чем компьютер :)
    • +15
      Для этого есть Chrome OS. :D
  • +2
    Прикольно, что даже Flash и Silverlight используются 64-битные. И 64-битным является не только главный процесс (как это по дефолту у ИЕ, например), но и все дочерние, включая процесс рендеринга. Т.е. всё это можно воспринимать не как эксперимент, а как действительно полный переход на х64.
  • 0
    Сколько теперь оперативки сожрёт Хром, прежде чем упасть на просмотре галереи в Dropbox? Сейчас падает после примерно 200 картинок и 3.7Gb сожранной оперативки.
    • 0
      Надо переставать пользоваться галереями Dropbox. Мало того, что сам Dropbox в разы дороже подобных решений от других вендоров (сегодня только у себя в блоге опубликовал сравнение), у него реализация галереи по-моему скомунизжена из Adobe Photoshop 1.0 — там какой-то жуткий HTML, который при любом раскладе показывается в махонькой области в центре экрана. Я клиентам фото отправляю либо в zip файле (и тогда Dropbox — отличное решение), либо в виде галереи (и тогда ничего лучше Picasa еще не нашел).

      Хром, конечно, не без недостатков, но в данной конкретной ситуации проблема у Dropbox. 1000 картинок в Picasa/Google+ отображается нормально.
      • 0
        У яндекс диска тоже галерея красивая, в box мелковатая
  • +34
    Столько глупых и нелепых комментариев я еще ни у одного топика на Хабре не видел.
    Филиал ВиО мейл.ру прям.
    • +6
      Ко-ко-ко, хром есть память!
  • 0
    Подскажите, как достоверно убедится что запускается именно 64х битная версия?
    • +3
      В винде в процессах к не-64-приложениям дописывается " *32". Не знаю насколько это достоверно.
      • 0
        Спасибо
    • +2
      открыть диспетчер задач
  • 0
    Через сколько под мак будет? И можно ли надеяться, что он будет меньше сажать батарейку, чем 32 версия?
    • +3
      Ну бит же больше, значит и сажать будет больше :)
    • –1
      я бы не стал так усердно ждать. в тех же макбуках всего 8-16Gb памяти, там 64 бита скорее во вред.
      • +5
        Всего? Вы откуда?
      • –1
        в тех же макбуках всего 8-16Gb памяти

        Нормально… Я только недавно ноут с 6 гб ОЗУ купил и доволен.
        Сомневаюсь, что у сколь-нибудь большого количества читателей хабра на компах с виндой/линупсом установлено больше 16 гб. Рискну предположить, что даже больше 8 гб нечасто встречается.
  • 0
    Если что, по вот этой ссылке можно скачать 64-битный Хромиум, верхняя папочка содержит самый новый снепшот.
  • 0
    Поставил Chrome dev. Получил кривые шрифты в интерфейсе и размытые иконки расширений. HTML-страницы тоже корявато отображаются.
    Переключил масштаб в настройках экрана со 125 на 100 процентов и всё стало ок.
    Но для меня совсем не вариант — FullHD на 15-дюймовом буке вынуждает вернуться к прежнему масштабу.
    • 0
      На Chromium 64 не работает Flash Player…
      • 0
        На Chrome пашет. Версия: 14.0.0.125
        • 0
          Хм. А где вы 125 билд нашли? Даже с сайта адоби 122 устанавливается. И в хромиуме она не работает.
          Может, в Хром встроен этот флеш плеер?
          • 0
            Да, встроен. Ничего не трогал. Видимо, Adobe Гуглу выделила на dev канал свежак потестить
    • 0
      Такая же фигня… Спасибо что подсказали как решить проблему =) Надеюсь в следующем билде решат…
  • 0
    О! Есть повод перейти обратно (сейчас сижу на Waterfox).
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Waterfox это и есть 64-битный Firefox. Только обновляется долго. Да и синхронизация сломалась с последней версией.
  • +9
    Прошло 11 лет после выпуска настольного 64-бит процессора, 13 лет после того, как на него портировали Линукс, и лет 10 после того, как портировали движок рендеринга KHTML. И вот Google начала тестировать AMD64-сборку своего форка KHTML под Windows.
    • +5
      Это показатель того, насколько 64-битность большинству приложений совершенно не нужна. Я не убеждён, что и Хрому нужна. Комментарии выше про отжирание памяти тому в подтверждение. А учитывая, что цена на память взлетела и не опускается, тем более.
      • +2
        А он один фиг делает кучу процессов на каждый чих, так что проблемы с ограничением выделенной памяти под программу ему не грозят. А оптимизация не настолько заметна, чтобы бросить все и срочно делать 64-бит версию.
      • 0
        Если бы AMD64 было большинству не нужно, Intel не делала бы бюджетных AMD64-процессоров. Atom и Core i3 были бы 32-битными, например, а i5 с i7 — 64-битными.

        Но нет, процессоры — 64 бита, ОС — 64 бита (даже Windows XP c 2005 года), прикладные программы от производителя ОС — 64 бита.

        То, что люди продолжают ставить на компьютеры ОС для старой архитектуры, программы для старой архитектуры — это ненормально и вредно для развития отрасли. То, что программисты продолжают создавать код для старой архитектуры — это ещё более ненормально и вредно.

        Всё это сродни нездоровой любви нашего общества к Windows XP и IE6.
        • +1
          ОС 64-битная нужна — просто потому, что сейчас 4 гигов оперативной памяти (включая, к слову, и видеопамять!) уже мало. Другое дело, что вот конкретно прикладным приложениям эти 64 бита не нужны совершенно! Если одно приложение кушает больше 4 гигов оперативной памяти, это либо какое-то специфическое приложение, вроде автокада или 3д макса, либо что-то очень неоптимизированно потребляющее память (вроде, ИМО, того же Хрома). Даже суперсовременные игры умещаются в эти 4 гига оперативной памяти и собраны в 32 бита!
          • 0
            Более того, даже для оси 64 бита не так уж нужны, если оставаться в рамках 64 гигов для всех и 3 гигов для одного приложения. Адресация за пределами 4 гигов возможна и на 32 битах. Другой вопрос, что в МС почему-то решили искусственно ограничить 32-битные винды 4 гигами (ну, тремя с половиной), просто подкрутив числа в «лицензии» и оправдавшись «дрова не очень хорошо работают».
          • 0
            Если это единственная причина — то нет, не нужна.

            32-битные ОС могут адресовать до 64 ГБ оперативной памяти (Линукс, например, с 1999 года), столько на домашних компьютерах всё ещё нет.
    • 0
      Хром на момента релиза (5 версия) и до сих пор всегда был и остаётся 64-битным. Неужели есть большие сложности сборки разных архитектур на m$ windows/macOS? И почему такого бардака (кроме проприетарного skype от m$, конечно) с битностями нет на линуксах?
      • 0
        Вы как бы сами себе ответили. Или даже не поняли?

        Под Linux'ом нет «такого бардака» потому что под него вообще мало что есть. Ни PhotoShop'а, ни AutoCAD'а, ни сотен (а то и тысяч) корпоративных творений с NPAPI модулями. А под Windows — всё это есть и это и является её главным преимуществом. Но вот всё это переводить на 64 бита — долго и сложно. Потому и не торопились.

        Поскольку Chrome собирается отказаться от NPAPI, то сейчас острота проблемы совместимости снизилась, так что да, теперь — можно. Вот и всё.
        • 0
          Слишком много эмоций, нельзя так.
          Вопрос по другому — в чём конкретно принципиальная сложность перевода на 64 бит? Да и брать тот же хром — он изначально под линуксы был 64 бит и гугл как-то не жаловался на проблемы совместимости и оптимизации. Что же самому гуглу помешало сделать 64 битнй хром для маков/вин сразу?
          • +1
            Вы снова и снова пропускаете нулевой пункт («а нафига оно вообще кому-либо нужно?») — и потому ищите ответ не на тот вопрос. Вы спрашиваете: кто мешает перейти — но ведь ответ на этот вопрос очевиден даже не на 100%, а на все 200%! Перейти нельзя пока у пользователей есть 32-битные OS! А ведь и сейчас ещё продаются железки с 32-битной Windows!

            Всё, что можно сделать — это добавить 64-битную версию, то есть добавить ещё одну платформу — и как и с любой другой платформой этого «просто так» никто делать не будет, нужны взвесить все за и против (причём вариант «ничего не делать», понятно, — умолчальный как требующий минимум затрат).

            Под линуксы Chrome изначально пришлось поддерживать и 32-бит и 64-бит, потому что разработчики оных линуксов забили на поддержку 32-битных программ в 64-битной OS (по иронии судьбы сейчас с ней всё гораздо лучше) и 32-битную программу в 64-битной OS просто было сложно использовать. Потому 64-битная версия и была выпущена — чтобы облегчить жизнь пользователям.

            В случае же с Mac'ом и Windows таких проблем никогда не было (и там и там 32-битные версии программ отлично работают в 64-битных операционках), а зато проблемы совместимости с NPAPI plugin'ами, наоборот, были.

            Сейчас потихонечку ситуация меняется (у меня на рабочем компе, скажем, 64GiB оперативки стоит) и уже возникает потихоньку желание перевести сам Chrome в 64бита чтобы можно было использовать больше памяти — что, собственно, и осуществляется. Но главное — планируемый отказ от NPAPI развязывает руки: если поддерживать NPAPI-plugin'ы мы больше не собираемся, то нас уже не волнует тот факт, что бо́льшая их часть не имеет 64-битных версий.

            Баланс сил изменился и было решено 64-битную версию всё-таки выпустить. За счёт отказа от одной из Linux'овых платформ, кстати (раньше версии для ChromeOS и обычного Linux'а сильно отличались: ChromeOS был построен на Aura, а обычный Linux'овый Chrome — на GTK… сейчас от версии на основе GTK отказались).
            • 0
              Сейчас от gtk отказались и он стал страшен как адовый рекламный баннер, что очень печально, а совместимость с нативными движками тем оформления так и не допилили — тянет только цвета и иконки (мне должно быть всё ровно как оно работает, но выглядеть стало гораздо хуже). В линуксах нет никаких проблем с битностью, просто все нужные библиотеки придётся дублировать в x32 варианте (точнее это будет делать пакетный менеджер), что не есть гуд по идеологическим и эстетическим соображениям (в вин это решается запихиванием всех либ в одну программу, не красиво, но решает проблемы совместимости). Да, понимаю, что софта таки мало (он есть, но мало), тем не менее в битности никто не обделён (кроме, опять же, скайпа) — ни всякие свободные редакторы, ни майя, ни вообще что-бы то ни было. То есть с появлением x64 наличие сборок под 32 и 64 является само собой разумеющимся (да и серверные системы сбрасывать со счетов не будем, там свой софт). Интересует почему эта «культура» не затронула другие системы. Действительно ли имеют место быть серьёзные технические проблемы, увеличивающие траты на поддержку архитектур?
              • 0
                Интересует почему эта «культура» не затронула другие системы.
                Может, просто потому, что для них есть куча более не поддерживаемого производителем 32-битного (если не 16-битного) софта без исходников?
                • 0
                  А даже если и есть исходники — что с того? Поймите: принцип «работает — не трогай» он основополагающий. Как выход новой версии какого-нибудь Civic'а (или Bentley) не приводит к тому, что все кидаются обновлять весь парк, так и к софту люди относятся. Любое изменение где-угодно требует обоснования.

                  Программистам (да и не только им) очень тяжело это понять (потому что не хочется), но это простая экономика. Конечно гораздо «веселее» и «приятнее» заменить в доме всё сантехнику, вместо того чтобы ковыряться в полусгнивших трубах, но, увы, это заметно дороже, так что приходится ковыряться.

                  То же самое и с программами: там, где их делают за деньги (а не «для души») никто не будет переписывать что-либо только потому, что у них появился новый расчудесный 64битный процессор. Вот когда кто-то скажет какая от такого переписывания будет польза — вот тогда и только тогда этот вопрос начнёт обсуждаться. Да и то — результат может оказаться далеко не в пользу переписывания.
                  • 0
                    С исходниками кто-нибудь мог бы и перенести, если бы это было выгодно, тем более, что где-то весь перенос, возможно, заключался бы в простой перекомпиляции. А без исходников единственный вариант — переписать заново. И да — с исходниками и «забесплатно» часто делают, если речь о FOSS.
                    P.S. Поддержка устаревшего железа, для которого давно не выпускают комплектующих — она тоже, знаете ли, не бесплатная и выходит заметно дороже поддержки современного. Взять, скажем, стоимость SIMM-модулей памяти.
              • 0
                В линуксах нет никаких проблем с битностью, просто все нужные библиотеки придётся дублировать в x32 варианте (точнее это будет делать пакетный менеджер)
                Если бы это было так, то никто бы не стал городить огород с 64-битным Хромом. Увы и ах, но нормально заработало это только в последние 3-4 года. До этого многих 32-битных библиотек ваши любимые «пакетные менеджеры» не предоставляли и, главное, не было ну никакой возможности поставить пакет от 32-битной системы на 64-битную на системах произведённых от Debian'а (в первую очередь Ubuntu)! Сейчас эту проблему вроде как разрулили, но так как 64-битный Chrome для Linux'а уже есть, то убивать его не стали.

                Действительно ли имеют место быть серьёзные технические проблемы, увеличивающие траты на поддержку архитектур?
                Не знаю насколько эту проблему можно назвать технической, но да, есть, разумеется. Называется Q&A. В «классическом» Linux'е на него, зачастую, просто забивают (почему он и обречён прозябать на уровне 1-2% рынка и никогда за эти пределы не выйдет), а на других платформах — это существенная часть затрат. Даже если у вас код для двух разных систем совпадает на 99% все неавтоматизированные проверки при введении поддержки 64-битных систем (и неотказе от 32битных) придётся делать дважды.

                Потому настоящий переход на 64бита на других платформах случится не тогда, когда появятся 64-битные процессоры, а когда исчезнут 32-битные! А до этого — ещё несколько лет.
                • 0
                  Ну и фиг с ним с этим линуксом, пускай не выходит из процента, а ответ на вопрос я так и не увидел. Упоминание первого у вас явно вызывает сильные эмоции.
                  • 0
                    Ну хорошо. Давайте я переведу ваш вопрос с русского на русский: «почему после выхода нового «вкусного» 64битного железа никто не ринулся выкидывать деньги на ветер и не стал переписывать программы, которые и в 32битном виде отлично работают?» — неужели этот вариант ещё требует какого-то ответа, кроме риторического?

                    Да потому что это не нужно никому нафиг! Вот и всё. Зачем делать работу, которую можно не делать? Что тут непонятного-то? Будут причины перейти на 64 бита — перейдут.
                  • 0
                    Дополню khim: сложилась ситуация, что софт, который требовал работы с большими числами уже очень и очень давно использует наборы SSE и др. спец инструкции, для примера можно взять видеокодеки, декодеры и т.д. По этой причине для большого количества софта даже эффекта от переписывания на 64 бита нет никакого, или он близок к нулю, а проблем с совместимостью с внешними либами и затратами на тесты тьма.
                    Единственные кому реально нужны 64 бита это программы способные утилизировать память в больших объёмах, всё остальное уже давно переписано с использованием векторизации и чудесно работает.
  • 0
    Вопрос к тем, кто попробовал: только у меня верхний край вкладок немного уехал за границу монитора? Как можно починить теперь? Переустановка stable версии не помогла, багрепорт написал…

    • 0
      Экономят ваше вертикальное пространство на мониторе.
      • 0
        Вот что называется оптимизм :)

        Проблему решил удалив свой профиль и потом по кускам восстановив закладки, настройки и т.д.
  • 0
    blogs.technet.com/b/srd/archive/2013/12/11/software-defense-mitigating-common-exploitation-techniques.aspx

    Интересные данные по энтропии

    DLL images based above 4 GB: 19 bits of entropy (1 in 524,288 chance of guessing correctly)
    DLL images based below 4 GB: 14 bits of entropy (1 in 16,384 chance of guessing correctly).
    EXE images based above 4 GB: 17 bits of entropy (1 in 131,072 chance of guessing correctly).
    EXE images based below 4 GB: 8 bits of entropy (1 in 256 chance of guessing correctly).


    Нашел показатели энтропии непатченного ядра linux (патчами можно еще увеличить)

    Anonymous mapping randomisation test: 28 bits (guessed)
    Heap randomisation test (ET_EXEC): 14 bits (guessed)
    Heap randomisation test (PIE): 28 bits (guessed)
    Main executable randomisation (ET_EXEC): 28 bits (guessed)
    Main executable randomisation (PIE): 28 bits (guessed)
    Shared library randomisation test: 28 bits (guessed)
    Stack randomisation test (SEGMEXEC): 28 bits (guessed)
    Stack randomisation test (PAGEEXEC): 28 bits (guessed)
    Arg/env randomisation test (SEGMEXEC): 20 bits (guessed)
    Arg/env randomisation test (PAGEEXEC): 20 bits (guessed)
    Randomization under memory exhaustion @~0: 28 bits (guessed)
    Randomization under memory exhaustion @0: 28 bits (guessed)


    А какие данные у других платформ?
  • 0
    Мониторы 22 дюйма. Вин 8. Пользуюсь виндовой настройкой размера всех элементов — 125%.
    С переходом на Хром х64 (возможно битность не при чём, но я заметил именно в момент перехода) в хроме всё стало ощутимо больше (режим 100%), очевидно браузер использует системную настройку.
    Тот же хабр в ИЕ при зуме 100% примерно равен 90% Хрома, но в хроме макет во всю ширину, в отличие от ИЕ и 2х Опер (на разных движках).
    Меня, как пользователя, это устраивает, но, как разработчику, становится не понятно, как тестировать макеты.
    х86 версия хрома исчезла после установки х64. Как то это напоминает историю с версиями ИЕ :(

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.