Comments 69
Ура, товарищи!
они начинают болеть той же болезнью что и firefox?
при всё при этом пренепременно УРА!
На самом деле, это началось с Chrome.
По большому счету, они просто отбросили первую цифру номера. Похоже, Линус решил, что ветка 2.* в разумном будущем не претерпит изменений, по масштабу сравнимых с 1.* -> 2.*, и поэтому можно просто отбросить первую цифру. В результате вторая цифра (4 в данном случае) просто меняется примерно с той же скоростью, с которой разньше менялась третья (2.6.*).
Да, нумерация рванула. На 2.6 сидели несколько лет, а казалось бы 3.0 появилась совсем недавно. Веяния моды…
Кстати, я почесав в затылке включил у нас в проекте линейную нумерацию (вообще без точек). Зачем делать версию 0.3.4.12 и увеличивать минор, когда можно просто называть версию «12» и делать ++ с каждой версией?
Ну хотя бы затем, чтобы отличать разные ветки при разработке продукта:
Как 0.5.0 — stable, 0.5.0.x — fix-ы в stable, 0.6.0 — новая функциональность, 0.5.1 — backport новой функциональности в старую ветку. Можно и другое что придумать с такой схемой.
На мой взгляд удобнее и нагляднее, чем линейная нумерация.
Как 0.5.0 — stable, 0.5.0.x — fix-ы в stable, 0.6.0 — новая функциональность, 0.5.1 — backport новой функциональности в старую ветку. Можно и другое что придумать с такой схемой.
На мой взгляд удобнее и нагляднее, чем линейная нумерация.
У нас ветка кодируется названием. То есть foobar-13, barbaz-12 и т.д.
Названия осмысленные, или такие как в примере (или как у Убунту, где, если бы не было номера версии, я бы не знал кто в этом зоопарке старше, а кто младше)?
Пример с убунтой немного мимо, там названия по алфавиту кодируются.
:) С убунтой понял, не знал, спасибо. А у вас?
У нас все проекты по версиям. Исторически так сложилось, и менять врядли будем.
По версиям — всмысле:
— в двух проектах — x.y.z, z — в основном багофиксы и мелкие фичи, y — минорные версии, x — мажорные версии, крупные-глобальные изменения (меняется очень редко).
— еще в одном — x.y, y — багофиксы-мелкие фичи, x — мажорные апдейты, крупные фичи (меняется достаточно часто, другая методология разработки).
— в двух проектах — x.y.z, z — в основном багофиксы и мелкие фичи, y — минорные версии, x — мажорные версии, крупные-глобальные изменения (меняется очень редко).
— еще в одном — x.y, y — багофиксы-мелкие фичи, x — мажорные апдейты, крупные фичи (меняется достаточно часто, другая методология разработки).
Т.е. Wary Warthog (4.10) — это последняя версия Ubuntu?
Кстати, интересно, что они будут делать, когда алфавит кончится?
Кстати, интересно, что они будут делать, когда алфавит кончится?
wiki.ubuntu.com/DevelopmentCodeNames#History
For all of our sanity we are going to try to keep these names alphabetical after Breezy.
For all of our sanity we are going to try to keep these names alphabetical after Breezy.
названия метасинтаксические. хахахаха!
Вот, кстати, самое здравое объяснение. Причем подсознательно мы все это понимаем. Что мажорная версия ну это что то совсем такое. Минорная — новый функционал. А дальше — фиксы. Это же удобно и испокон веков уже.
Спасибо, буду использовать ваш комментарий как здравый аргумент в холиварах =)
Спасибо, буду использовать ваш комментарий как здравый аргумент в холиварах =)
Эм, а тогда не будет путаницы в версиях?
Если они выпускаются достаточно часто, то вполне вероятно, что будут версии типа «1489» и «1523» — и не понятно, насколько их содержимое близко друг к другу.
Если они выпускаются достаточно часто, то вполне вероятно, что будут версии типа «1489» и «1523» — и не понятно, насколько их содержимое близко друг к другу.
потому что всю жизнь изменение третьей цифры означало багфиксы и, возможно, новые функции с полностью сохраняющейся структурой и результатами выдачи старых, изменение второй цифры означало внутренние изменения функций и глобальное расширение функционала с сохранением совместимости со старыми версиями, а изменение первой цифры означало крадинальное изменение функций, никаких гарантий обратной совместимости.
Да, в генту такое бывает) Именно поэтому на работе поставил в свое время Убунту — чтоб не поднимать по пол дня.
Ключевым изменением стало (имхо) включение штатного i915 в режим энергосбережения (rc6).
> Поддержка x32 ABI — 64-битный режим работы с 32-битными указателями;
Кто-нибудь может популярно объяснить что это и зачем нужно?
Кто-нибудь может популярно объяснить что это и зачем нужно?
Выглядит очень оптимистично! Я так понимаю, что компилить надо тоже как-то особенно.
как раз нет, судя по всему это как раз для тех приложений, которые собраны для 32 разраядной платформы, а работают 64 разрядной, и пересобрать их нет возможности (или смысла). Так что это улучшение как раз для уже собранных приложений, если так можно выразиться.
Тогда имеет смысл всё, что умещается в 4 гига компилить под 32 бита, и получать прирост скорости и экономию памяти?
Нет, приложения которые «собраны для 32 разраядной платформы, а работают 64 разрядной, и пересобрать их нет возможности (или смысла)» и так работают.
Тут суть в том, чтобы скомпилировать приложения использовав все вкусности x64, но при этом 32-битные указатели.
Тут суть в том, чтобы скомпилировать приложения использовав все вкусности x64, но при этом 32-битные указатели.
В режиме x86 у нас есть 8 32-битных регистров и 8 FP-регистров, FP вычисления происходят через x87, указатели занимают 32 бита, аргументы функции передаются через стек.
В режиме x86_64 есть уже 16 64-битных и 16 FP-регистров, FP вычисления происходят с помощью SSE, указатели занимают 64 бита, аргументы можно передавать через регистры.
x32 — это попытка взять лучшее от обоих режимов для тех программ, которым достаточно 32 бит для структур/указателей, то есть получаем: 16 64-битных и 16 SSE-регистров, вычисления на SSE, указатели 32 бита, аргументы через регистры.
(32-битный программы, конечно, придётся перекомпилировать в режиме x32)
В режиме x86_64 есть уже 16 64-битных и 16 FP-регистров, FP вычисления происходят с помощью SSE, указатели занимают 64 бита, аргументы можно передавать через регистры.
x32 — это попытка взять лучшее от обоих режимов для тех программ, которым достаточно 32 бит для структур/указателей, то есть получаем: 16 64-битных и 16 SSE-регистров, вычисления на SSE, указатели 32 бита, аргументы через регистры.
(32-битный программы, конечно, придётся перекомпилировать в режиме x32)
Мало того, что программы надо перекомпилировать, так ещё и libc нужен с x32. Попробую это протестирость, но на рабочей машине это не так то просто.
Мне как раз очень нужен SSE, а памяти на около 2-3 гигов на 8 потоков хватает, так что скорее всего выгода какая-то будет.
Мне как раз очень нужен SSE, а памяти на около 2-3 гигов на 8 потоков хватает, так что скорее всего выгода какая-то будет.
А зачем эту штуку реализовывать? Не проще перейти сразу на 64-битную систему?
Для увеличения скорости где можно и уменьшения расхода памяти. Хотя ничего не делать конечно всегда проще %)
Зато снова появляется возможность использовать баги фичи линии А2032. Из программы напрямую недоступны данные по адресу 4G+4 (или доступны определённым образом), а при передаче в ядро (read, например), всё работает.
Как я понял, это больше изменений для gcc, которым надо поддерживать новую архитектуру, чем для ядра.
Исключительно из спортивного интереса волнует вопрос работы дискретной Nvidia видухи с процессорами линейки Ivy Bridge и Sandy Bridge — удалось ли наладить эту работу без костылей типа ironhide и blumblebee?
К сожалению, в changelog ни слова про nvidia optimus.
Всё-таки я последний раз ковырялся с ними когда только 3.0.0 ядро вышло, может в 3.1, 3.2, 3.3 что-о поменялось? Или может костыли стали более стабильными? Когда я их трогал последний раз, результат манипуляций был совершенно непредсказуемым…
а с дискретной amd совсем беда
ни reiser4 ни pohmelfs так и не запилили.
Плачу.
Плачу.
Знатоки Линукс, а скажите такую вещь — в новом ядре заявлена поддержка новых карточек от NVidia и ATI. Т.е. эти видеокарты не функционировали до выхода ядра? Ведь и та и другая компания, насколько я помню, выпускает дрова под линукс. Зачем нужна поддержка в ядре?
> Зачем нужна поддержка в ядре?
В ядре — открытые драйвера, от производителей — закрытые.
В ядре — открытые драйвера, от производителей — закрытые.
В ядре часть открытых драйверов. Для nvidia они получены реверсиженериногом, а у ATI спеки открыты. Хотя поддержка местами не полная, но все же эти драйвера в некоторых случая могут оказаться вполне приемлемыми. К тому же они поддерживают некоторые фитчи, которые закрытые драйвера не поддерживают, например KMS или работу внутри Xen. Работают из коробки и как правило не ломаются с выходом новой версии ядра/xorg, т.к. вместе с ними идут и их новые версии.
У пингвина живот все растет или мне кажется?
Меня настораживает, что Линукс перешёл на новую нумерацию ядер. Если раньше было 2.6.х к примеру, то сейчас 3.х. Кто-нибудь знает почему и зачем?
Не холивара ради, просто интересно.
Не холивара ради, просто интересно.
Обновление за обновлением, а старые сканеры так и не поддерживаем. Лежит куча этих сканеров мертвым грузом!
>>Модуль безопасности Yama;
звучит как шутка
звучит как шутка
Sign up to leave a comment.
Ядро Linux обновилось до версии 3.4