Доступен (https://lists.debian.org/debian-devel-announce/2015/03/msg00...) второй кандидат в релизы инсталлятора Debian 8.0 "Jessie". В настоящее время насчитывается (http://bugs.debian.org/release-critical/) 112 критических ошибок, блокирующих релиз. С учётом тривиальных проблем и недоработок, для которых уже готовы патчи, для выпуска релиза остаётся исправить (https://www.debian.org/News/weekly/2015/02/#rcstats) примерно 67 ошибок.По сравнению с прошлой (http://www.opennet.me/opennews/art.shtml?num=41538) тестовой версией в основном отмечаются исправления ошибок, расширение поддержки оборудования и мелкие корректировки пакетной базы (например, из набора desktop исключены пакеты pm-utils и libgl1-mesa-dri). Что касается оборудования, то добавлена возможность загрузки 64-разрядного ядра Linux в 32-разрядном окружении EFI, улучшена обработка возврата UEFI-прошивками некорректных кодов ошибок, обеспечена поддержка систем Bay Trail, Buffalo Linkstation LS-CHLv2/LS-XHL, OMAP5432 uEVM, LinkSprite pcDuino V3, Bananapro, LeMaker Banana Pro, A20-OLinuXino-LIME2. В ALSA реализована сборка в виде модулей подсистем SND_SOC, SND_SOC_INTEL_SST,
SND_SOC_INTEL_HASWELL_MACH, SND_SOC_INTEL_BYT_RT5640_MACH,
SND_SOC_INTEL_BYT_MAX98090_MACH.Основные особенности (https://wiki.debian.org/ReleaseGoals) Debian 8.0:
- Использование (http://wiki.debian.org/systemd) по умолчанию системного менеджера systemd;
- Поддержка Clang в качестве вторичного компилятора;
- Обеспечение возможности использования системы принудительного контроля доступа SELinux (в режиме enforcing);
- Задействование дополнительных механизмов (https://wiki.debian.org/Hardening) обеспечения безопасности, интегрируемых в исполняемые файлы ELF (Position Independent Executable, защита стека, Fortify Source, Read-only relocations, Immediate binding). Активация (https://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildF...) флагов сборки с использованием дополнительных механизмов безопасности для как можно большего числа пакетов, которые работают с внешними данными (сетевые серверы, браузеры, просмотрщики контента и т.п.);
- Включение (https://wiki.debian.org/ReleaseGoals/CrossToolchains) инструментов кросс-компиляции в архив и обеспечение из коробки средств для кросс-сборки (https://wiki.debian.org/ReleaseGoals/CrossBuildableBase) базовой системы (можно будет разом и без установки внешних инструментов кросс-скомпилировать 140 пакетов, составляющих минимальную базовую систему);
- Упорядочивание использования сборочных флагов CC/CXX;- Проведение чистки архива пакетов для прохождения пакетами тестов piuparts (https://wiki.debian.org/ReleaseGoals/piuparts);
- Полная поддержка (https://wiki.debian.org/ReleaseGoals/utf-8) UTF-8 во всех пакетах (поддержка ввода и отображения в UTF-8 по умолчанию, поставка всех текстовых файлов в UTF-8, поставка в пакетах файлов только с именами в кодировке UTF-8).- Замена СУБД MySQL на MariaDB 10.0;- Обновление версий программ, в том числе GNOME 3.14, LibreOffice 4.3, Calligra 2.8, apache httpd 2.4.10, exim 4.84, postfix 2.11, openssh 6.7, perl 5.20, php 5.6, python 3.4, postgresql 9.4, samba 4.1, ядро Linux 3.16;- Многочисленные улучшения (http://www.opennet.me/opennews/art.shtml?num=40911), связанные с поддержкой мультимедиа.
URL: https://lists.debian.org/debian-devel-announce/2015/03/msg00...
Новость: http://www.opennet.me/opennews/art.shtml?num=41921
>Полная поддержка UTF-8 во всех пакетах (поддержка ввода и отображения в UTF-8 по умолчанию, поставка всех текстовых файлов в UTF-8, поставка в пакетах файлов только с именами в кодировке UTF-8)Это теперь man man в ru_RU.UTF8 починят? Невероятно
Как это они mesa вырезали? Интересно почему?
> Как это они mesa вырезали? Интересно почему?Из-за 64 бит ,прошивки видеокарт и стандарт не тестировался (и вообще не предусматривалось ) на 64 битный режим .Хрен его знает как поведет оборудование даже в 32 битном режиме если кто-то воспользуется Kvm или виртуал боксом с 64 разрядной операционкой .Наверно подстраховались что бы случайно не загрузить модуль ядра :-(
Т.е что, никакого 3D теперь чтоли?
надо потом доустановить, видимо, когда станет ясно, что десктоп рисуется хотя бы программно
> Т.е что, никакого 3D теперь чтоли?Gallium3D -это стандарт теперь ари .Mesa -тоже развивается ,только в качестве компонента включенного в галиум .
Наоборот - gallium это подпроект в mesa. Он позволил унифицировать некоторые части драйверов. Mesa dri нужен всегда, просто реализован может быть с gallium или без.
Хм ,на хабре в статье графическая система linux говорилось что галлиум прослойка между dri и open gl .Статье я верю потому что есть пристройка к галлиуму -реализуещееся directx 9 полностью и частично до 11версии ,не завищееся от open gl .
Не совсем так. Mesa условно можно разделить на две части: api (libGL) и драйвер (dri). Раньше каждый dri-драйвер реализовывал все сам (dri1). Потом решили унифицировать части, которые есть во всех драйверах и назвали gallium/dri2:
https://en.wikipedia.org/wiki/Gallium3D#/media/File:Gallium3...Это упростило подключения новых api (dx9, dx11) и облегчило портирование на другие системы. Ну и само собой стало проще писать новые драйвера.
https://en.wikipedia.org/wiki/Gallium3D#/media/File:Gallium3...
> Это упростило подключения новых api (dx9, dx11) и облегчило портирование на другие
> системы. Ну и само собой стало проще писать новые драйвера.
> https://en.wikipedia.org/wiki/Gallium3D#/media/File:Gallium3...А к ари Vulkan архитектура gallium подойдет ? А то смотрю что многое из архетектуры и компонентовVulkan пересекается с gallium :-(
На сколько я понимаю, vulkan - это практически тот же gallium, только с официальным api. Основное различие в IR (Intermediate Representation): у mesa - mesa ir (сейчас внедряется nir), у vulkan - spir-v. Так как spir основан на llvm, а mesa уже использует llvm для шейдеров, можно предположить, что различаются они не глобально. Тем более, что mesa единственный в своем роде проект, поддерживающий различные api, железо и платформы/архитектуры, так что vulkan явно создавался с оглядкой на опыт mesa.
> Как это они mesa вырезали? Интересно почему?Единственное разумное объяснение - OpenGL сам по себе бесполезен, если не установлены программы его использующие.
> Как это они mesa вырезали? Интересно почему?
* Remove libgl1-mesa-dri from the desktop task list. xorg depends on it,
so it does not need to be explicitly listed.http://metadata.ftp-master.debian.org/changelogs//main/t/tas...
http://bazaar.launchpad.net/~vcs-imports/tasksel/master/revi...
таки пгостите, а как жить ноутбукерам без pm-utils
use systemctl luke
Да, вечная чехарда с этими управляторами питанием и охлаждением достали. Ставишь на новый ноут, он раскаляется добела, а всё почему? потому что в новом релизе всё по новому, "правильное".Немного оффтоп, но реально, достало!
А как жить, если новый ядерный интеловский pstate решил, что для охлаждения процессора сначала надо снизить частоту процессора до 290 мегагерц, а потом просто вырубить комп? А как же вентилятор? Он еле крутится! Это что за новшество? Раньше я отключал pstate нафиг и пользовался старым добрым acpi_cpufreq, с которым отлично работал вентилятор. Теперь же всё, не работает финт ушами, заботливые разработчики сделали "правильно". Зато системды ввели и лезбиянкам призы раздали...
для того systemd и потребен, чтобы была унификация. а не "я так делал в слаке, прочёв в сети рецепт 2001 года, и теперь попробую так же исхитриться в убунте".
> для того systemd и потребен, чтобы была унификация. а не "я так
> делал в слаке, прочёв в сети рецепт 2001 года, и теперь
> попробую так же исхитриться в убунте".сарказм?
Сам себе противоречишь. я как раз за то, чтобы рецепт 2001-ого года работал. я против того, чтобы базовые системы выкидывались и назывались устаревшими ровно в тот момент, как они почти уже начали работать. Почему надо было забрасывать acpi, acpid, pm-tools, laptomode-tools lm-sensors/fancontroll и пр. (остальные аббревиатуры забыл)? Где они, современные всеумеющие и правильные проекты? Нету? так нахрена ломать совместимость?
Потому что в одном дистре одно, в другом - другое, в третьем перескочили на четвёртое.Рецепт 2001 года работать не будет. Потому что оно может вообще по другим принципам развиваться - где-то перешли на 2.6 и его фишки, где-то - затачивают под 2.4
Для этого и нужна унификация, и единая внешняя обёртка. Чтобы вот эти все низкоуровневые вещи работали и везде управлялись одинаково. Чтобы кто-то не начинал делать дикие воркэраунды для врезания своих старых слаковских 2001-годных метотов "потому что он так привык". Потому что это может работать до первого серьёзного обновления, ибо система этого обновления даже представить себе не может, что кто-то вместо штатного способа будет использовать перекосабоченный.
Вот, реально, я ставлю OpenBSD 2.8, и, в принципе, довольно просто в ней ориентируюсь, и примерно понимаю, что делать. Хотя раньше её не видел.
А в Debian 3.0, 3.1, 4.0, 5.0, 6.0 - некоторые вещи работают иначе, а некоторые - совсем иначе. Вроде мелочь, но я постоянно хочу сделать, как я привык - и получаю не то. При этом, это работает как в сторону "от 3.0 до 8.0", так и обратно. А если разбавить эксперименты разными версиями слак, редхатов и прочего - то и получается то, что получается: ядро одно, гномы-кеды одни, а вот какую-нибудь мелкую штуку я не знаю, как сделать - потому что выбор средств велик, а выбор способов их взаимодействия - бесконечен.
Вообще, "Я так привык" может просто не работать в новой версии. Потому что, прочитав 1000 разных мануалов по разным проблемам ядра linux, я заметил, что примерно 90% из них работают на принцип "лишь бы здесь и сейчас залепу сделать", и не учитывают проблем обновления, проблем воспроизводимости в разных случаях, вопроса разных архитектур и т.п. Бедные авторы систем обновления вынуждены расширять зону "крайних случаев", чтобы учитывать все эксперименты из серии "когда-то прикрутил - и забыл", иначе это обновление просто будет рушить работоспособную систему.
С усложнением систем, количества архитектур, возможностей и системых утилит - унификация по таким вещам просто необходима. Иначе регулярно будет повторяться вся та серия проблем, о которых вы говорите - будет новая утилита, и её тоже будут дёргать напрямую, и будут те, кто привык дёргать старую. Потом выйдет третья, и у нас уже три слоя. На сегодняшний день - этих слоёв уже очень много :) И у каждого есть своя группа, привыкшая к нему. Из-за этого авторы какого-нибудь прикладного ПО должны поддерживать 15 таких систем :)
> Для этого и нужна унификация, и единая внешняя обёртка. Чтобы вот эти все низкоуровневые вещи работали и везде управлялись одинаково.И называется эта унифицированная обертка sysfs. Как не крути, а каждый DE все равно будет иметь свой конфигуратор.
>> Для этого и нужна унификация, и единая внешняя обёртка. Чтобы вот эти все низкоуровневые вещи работали и везде управлялись одинаково.
> И называется эта унифицированная обертка sysfs.Товарищ выше не говорит "я привык дёргать /sys/....", он говорит "я привык к определённым утилитам, а теперь они новые".
> Как не крути, а каждый DE все равно будет иметь свой конфигуратор.
Речь не о DE. Речь о том, что человеку, который хочет вбить команду в консоль для очевидной вещи (раньше он делал это сотни раз), и получает отказ - будет чувствовать себя некомфортно. Вроде всё так, вроде всё есть, а пошёл вентиляторы настроить - и пустота.
> Речь не о DE. Речь о том, что человеку, который хочет вбить
> команду в консоль для очевидной вещи (раньше он делал это сотни
> раз), и получает отказ - будет чувствовать себя некомфортно. Вроде всё
> так, вроде всё есть, а пошёл вентиляторы настроить - и пустота.То есть при переходе на systemd сломали/удалили остальные frontend'ы к sysfs?
Я понял: были 100500 методов, а теперь появился еще один - systemd. Значит нужно делать свой.
Нет. Раньше дистрибутивы выбирали 100 методов, и все - разные. А теперь практически все дистрибутивы выбирают systemd, причём сами.
> А теперь практически все дистрибутивы выбирают systemd, причём сами.Как и демократию, ага.
>> А теперь практически все дистрибутивы выбирают systemd, причём сами.
> Как и демократию, ага.ты ещё скажи, что они Linux Kernel выбирают. Где Альт с ядром и базовой системой OpenBSD?
интел напишет своё системдэ для каждого поколения процов хотя бы за последние 7 лет?
>Ставишь на новый ноут, он раскаляется добела, а всё почему?Потому что у производителей ноутов руки из одного места? :)
Вернее, традиционно, на проблемы с охлаждением забивают -- ибо маркетолухи считают, что клиенту вся мощь железки не понадобится, а вот крутыми циферками его удивить надобно!
И пофиг, что в таком режиме ноут может проработать только пару минут -- это же традиция, к этому хомячков давно приучили, на этом еще и денюжку сделать можно (всякие кулпады впаривать)!
А если без излишних эмоций -- в большинстве проблем с ноутом (охлаждение, проблемы с дровами и т.д.) стоит все-таки винить производителя (ну и немного себя, любимого, решившего взять именно эту модель), но никак не разработчиков или мейтенеров.
Тоесть в том, что при обновлении или установке нового дистрибутива ломается работа того что уже работало и заменяется на очередной не работаюший, урезанный велосипед (в котором руль уже не поворачивается, колёса квадратные и повёрнуты перпендикулярно направоению движения, потому что по задумке авторов он правильный и просто должен работать) виноваты производители компьютеров? сколько велосипедов навелосипедили уже, посчитать?
> виноваты производители компьютеров?Если велосипеды требуются исключительно из-за наплевательского отношения производителей железа к поддержке не-форточко-осей, то да, трудно таки винить "изобретателей велосипедов" ибо без их костылей некоторые фичи вообще были бы не доступны (http://cgit.freedesktop.org/pm-utils/tree/pm/sleep.d/98video...).
Так же как и "зоопарк велосипедов" -- сами программы "контроля" достаточно просты, а большая часть усилий тратится как раз на поддержку базы данных с костылями для каждой конкретной модели (и авторам это когда нибудь надоедает).
И да,
> ломается работа того что уже работалоpm-utils ведь заброшен?
http://cgit.freedesktop.org/pm-utils/
ЗЫ: все равно -- "раскаляющийся добела ноут" как раз проблема криворукости производителей.
То, что продвинутые пользователи сразу ставят дополнительные программы для управления охлаждением и т.д., так как "мы привыкли и вообще -- традиция-с!" никак не на это не влияет.
> ЗЫ: все равно -- "раскаляющийся добела ноут" как раз проблема криворукости производителей.Ты вообще не понимаешь как это работает, да?
> То, что продвинутые пользователи сразу ставят дополнительные программы для управления охлаждением и т.д., так как "мы привыкли и вообще -- традиция-с!" никак не на это не влияет.
Я не ставлю дополнительных программ пока это не становится нужно. Это не привычка. Это необходимость по вине разработчиков именно ядра линукс. Они не дают acpi заниматься своим делом. Они перехватывают управление питанием, а на самом деле управлять-то и не умеют.
> привычка. Это необходимость по вине разработчиков именно ядра линукс. Они не
> дают acpi заниматься своим делом. Они перехватывают управление питанием, а на
> самом деле управлять-то и не умеют.
> Ты вообще не понимаешь как это работает, да?Конечно нет! Зачем мне знать тонкости впаривания какашек пользователям и правильного развода простачков маркетолухами?
А управлялка охлаждением у меня и дефолтная, "из кoробки ноута" неплохо работает -- в смысле, даже через час под полной нагрузкой, температура непосредственно цпу выше 80°C не поднимается.
А уж мой собственный велосипед (который перехватывает управление охлаждением при температуре цпу < 65°C) позволяет сейчас читать опеннет и писать вам ответ и вовсе при 40-42°C и выключенным вентилятором.> Они перехватывают управление питанием, а на самом деле управлять-то и не умеют
Ну-ну. Злые разработчики ядра линукса не дают нормально работать дефолтному режиму/управлялке -- это ведь не дело, когда все из каробки работает, это полный непорядок!
И всякие video-quirks, что бы саспенд работал, эти товарищи тоже сами внедрили -- что бы юзверям нескучно было!
> Я не ставлю дополнительных программ пока это не становится нужно. Это не привычка."Нужность" установки этих программ определяется при покупке железки, не? Если вначале купить, а потом поинтересоваться, что там с поддержкой линукса -- то да, может стать очень грустно. И в этом будут виноваты исключительно злые разрабы ядра линукса, а не белые и пушистые производители железок, действющие по принципу:
1. Тяп-ляп.
2. подогнать все параметры под специфику форточки и проверить там же (ведь все проблемы линукса, бзди и т.д. с ацпи -- исключительно из-за криворукости пингвиноидов, бздунов и остальных неосиляторов).
3. Впаривать пользователем!
4 Profit!Причем -- и под форточкой этакое "чудо" техники будет перегреваться (и/или все время гудеть вентилятором, пытаясь взлететь), достаточно загуглить "ноут выключается от перегрева".
Однако, самый прикол в том, что пользователи почему-то не жалуются в тех-поддержку, не негодуют в твиттерках и контактиках, а начинают устанавливать программки-управлялки и ограничители такта цпу, отключать турбо и покупать кулпадики и обмениваться опытом. Ну или плакаться на опеннете и обвинять разработчиков/мейнтейнеров линукса :)
>а начинают устанавливать программки-управлялки и ограничители такта цпуёпырный ты придурок... я же написал, что этим как раз занялись ёпырные разработчики интелловского линуксоядерного модуля! это ты понять можешь? Ещё расскажи, что мелкософт приплачивает производителям за то, что в линуксе температура проца на 10-15 градусов выше чем в винде, причём на любом ноуте любого производителя!
Не поленился, провел замеры, благо был под рукой ноут с двумя системами.
Старый intel 1.66MHz x 2 (toshiba) - в простое 44-47 градусов и под win и под linux. Время автономной работы тоже одинаковое показывает. Шум одинаковый.Под полной нагрузкой: win - 71C, linux - 69C. Можно списать на разный тип нагрузки.
Полная нагрузка linux с PHC: 55C! И шума соответственно существенно меньше.
> ёпырный ты придурок...Отличный аргументик!
> разработчики интелловского линуксоядерного модуля!Да?
> This driver provides an interface to control the P state selection for
> SandyBridge+ Intel processors.Или:
https://software.intel.com/en-us/blogs/2008/05/29/what-exact...Ну и? Казалось бы, причем тут вентилятор?
> А как же вентилятор? Он еле крутится!---
> это ты понять можешь?Что я должен понимать-то?
Внезапно, модуль пилится как бы интелем:
https://github.com/torvalds/linux/blob/master/drivers/cpufre...
> intel_pstate.c: Native P state management for Intel processors
> *
> * (C) Copyright 2012 Intel Corporation
>* Author: Dirk Brandewie <dirk.j.brandewie@intel.com>http://lkml.iu.edu/hypermail/linux/kernel/1302.0/02669.html
Так что тут выбор -- или пилить свой, "правильный" велосипед -- или включать модуль в ядро.
Причем и "старый добрый" acpi-cpufreq, ВНЕЗАПНО, не управлял вентилятором.Или речь все же не о intel-pstate, а о том, что последний релиз pm-utils был лет 5 назад и с тех пор никто не закоммитил ни строчки? Так от нытья на форумах о злобных разрабах и мейнтейнерах он никак не оживет, а вот внятных аргуметов, зачем дебианщикам возится с поддержкой заброшенного проекта -- не было.
> Ещё расскажи, что мелкософт приплачивает производителям за то, что в линуксе температура проца
Да не, зачем? Криворукие юзвери и сами с этим справятся :)
> на 10-15 градусов выше чем в винде, причём на любом ноуте
Ну да, ну да, в простое, типа -- читать опеннет и троллить^W печатать ответ, сейчас - 38-42 градусов (при выключенном вентиляторе, ибо нефиг).
В винде было где-то 43-45, при работающем на малых оборотах вентиляторе (замерял давно, сразу после покупки -- запустил primes на пару часов и потестил в разных режимах, поотключав все левые сервисы и программки производителя -- посмотреть на нагрев и расход батареи "из коробки, под сертифицированную ось", что бы знать примерные "нормальные" значения).Расход батарейки: разница примерно в 2-3 вт. в простое, как и в "idle + поотключать все нафиг и затемнить экран", причем отнюдь не в пользу форточки.
> любого производителя!
УМВРЧЯДНТ?
> Тоесть в том, что при обновлении или установке нового дистрибутива ломается работаСсылочку на ваш багрепорт можно?
> того что уже работало и заменяется на очередной не работаюший,Т.е., вы решили форкнуть pm-utils, что бы значит, не нужно было искать замену? Похвально!
Или, может быть, есть ссылочка на ответ вам/кому-либо, на вопрос, зачем впилили новый, "правильный" велосипед?
Или опять -- стандартное нытье на опеннете, какие все не-д'Артагнаны, как разрабы линукса и/или мейнейнеы вам должны -- просто по факту своего существования и
и как мужик с пистолетов за вашей спиной задолбал, заставляя пользоваться этим кактусом^W дистрибутивом пингвина, вместо замечательной оси, для которой и был сертифицирован ваш ноут! :)
> и лезбиянкам призы раздалиПочему это Вас так волнует? Возможно, у Вас есть детские воспоминания, связанные с этим?
Выставить при установке галочку напротив laptop?
> улучшена обработка возврата UEFI-прошивками некорректных кодов ошибокКак всегда - одни наговнокодят, другие головняк разгребают.
> В ALSA реализована сборка в виде модулей подсистем SND_SOC, ...Дальше по списку вообще-то обычные драйверы звуковушек, гругря. Причём не помню уже, были ль там грабельки под 3.16, но ситуация по baytrail заметно меняется от ядра к ядру и засовывать с достаточно старым осмысленно разве что на miniITX и подобное.
Желаю проекту удачи и хорошего выпуска.
с высоких гор спускается релиз ...
Где скриншоты нового кандидата ?
У каждого они будут свои.
Это значит что пора переходить на debian 7.8 wheezy
>Использование по умолчанию системного менеджера systemdВранье! "По умолчанию" предполагает возможность выбора а выбора там нет - только поделка поттера и все!
> "По умолчанию" предполагает возможность выбора а выбора там нетТы Release Notes читало, прежде чем свои сопли по интернету размазывать?
Я поставил upstart ради интереса. Только внутри vps оно после этого загружаться перестало. Так что выбор "поставить upstart и не загружаться" у тебя есть.Я уж не говорю про варианты при обновлении.
Wxgtk3.0 от которого wxmaxima и codeblocks падают - так и не починили
Не вижу отчета об ошибке:https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=libwxgtk3....
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=maxima;dis...
https://bugs.launchpad.net/ubuntu/+source/wxmaxima/+bug/1311770
Не пофиксили ни там, ни в дебиане
Вот в дебиане https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752528
> Wxgtk3.0 от которого wxmaxima и codeblocks падают - так и не починилии тут тоже:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=wxmaxima;d...
То есть раньше они собирали все это дело без -fPIE и -D_FORTIFY_SOURCE ? Какой позор!
> То есть раньше они собирали все это дело без -fPIE и -D_FORTIFY_SOURCE? Какой позор!То есть какой-то еще сопоставимый по размеру архив до этого собирался массово с этими опциями?
