The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз Debian 8.0 'Jessie', opennews (?), 26-Апр-15, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


25. "Релиз Debian 8.0 Jessie"  +2 +/
Сообщение от Аноним (-), 26-Апр-15, 09:47 
> Создана новая добротная основа
> на базе которой наверняка появятся качественные дистрибутивы. Такие, как семейство Ubuntu, варианты Linux Mint

Ни Ubuntu, ни LMDE не базируются на stable

Ответить | Правка | Наверх | Cообщить модератору

75. "Релиз Debian 8.0 Jessie"  +1 +/
Сообщение от Teocallyemail (?), 26-Апр-15, 14:10 
> Ни Ubuntu, ни LMDE не базируются на stable

А, ну тогда не нужно :)

Ответить | Правка | Наверх | Cообщить модератору

146. "Релиз Debian 8.0 Jessie"  +1 +/
Сообщение от freehckemail (ok), 27-Апр-15, 00:08 
> Ни Ubuntu, ни LMDE не базируются на stable

Ну да, конечно, LTS-выпуски Ubuntu базируются на Testing-ветках. Вот только выпускаются они с интервалом в 2 года. Примечательно, что Stable-ветки в Debian выпускаются с точно таким же интервалом.

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

152. "Релиз Debian 8.0 Jessie"  +/
Сообщение от Аноним (-), 27-Апр-15, 01:39 
> Ну да, конечно, LTS-выпуски Ubuntu базируются на Testing-ветках. Вот только выпускаются
> они с интервалом в 2 года. Примечательно, что Stable-ветки в Debian
> выпускаются с точно таким же интервалом.

Вот только у убунтуев есть еще и "обычные" релизы, позволяющие не сидеть с тухлым софтом на десктопе, но все-таки получить полгода дебиан-образной политики поддержания репов. Некий достаточно интересный баланс между хардкором роллинга и тухлостью стэйбла, на мой вкус. А у дебиана прямых аналогов просто нету. Все что есть - требует высший пилотаж пакетного манагера или чревато кучей проблем.

Ответить | Правка | Наверх | Cообщить модератору

155. "Релиз Debian 8.0 Jessie"  +2 +/
Сообщение от freehckemail (ok), 27-Апр-15, 02:36 
>> Ну да, конечно, LTS-выпуски Ubuntu базируются на Testing-ветках. Вот только выпускаются
>> они с интервалом в 2 года. Примечательно, что Stable-ветки в Debian
>> выпускаются с точно таким же интервалом.
> Вот только у убунтуев есть еще и "обычные" релизы, позволяющие не сидеть
> с тухлым софтом на десктопе, но все-таки получить полгода дебиан-образной политики
> поддержания репов.

А попробуйте ответить на банальный вопрос: какие-такие новые версии софта Вам нужны, и зачем?

> Некий достаточно интересный баланс между хардкором роллинга и тухлостью
> стэйбла, на мой вкус. А у дебиана прямых аналогов просто нету.

Да. Но знаете ли, не все считают хорошей идеей каждые полгода форкать testing и отдельно поддерживать. Сизифов труд, чесслово.

> Все что есть - требует высший пилотаж пакетного манагера или чревато
> кучей проблем.

Ой, ладно Вам, какой там "высший пилотаж". Это так нынче называется "перейти на testing"? )

Ответить | Правка | Наверх | Cообщить модератору

231. "Релиз Debian 8.0 Jessie"  +2 +/
Сообщение от Аноним (-), 27-Апр-15, 19:41 
> А попробуйте ответить на банальный вопрос: какие-такие новые версии софта Вам нужны, и зачем?

Linux kernel. Потому что я не некрофил и у меня бывает достаточно свежее железо. К тому же мне нравятся возможности btrfs и я им, натурально, пользуюсь.
MESA - затем что каждая новая версия работает лучше старой и мне не хочется связываться с блободрайверами и их проблемами.
KiCad - потому что мне пригодятся новые фичи.
Nginx - same.
Geany - аналогично.
ffmpeg/libvpx/libav - потому что я хочу поддержку VP9.
XFCE 4.12 - имеет ряд улучшений относительно старых версий. Не критично но приятно.

И на самом деле так куда ни ткни. Ну вот фороникс недавно ткнул: http://www.phoronix.com/scan.php?page=article&item=ubuntu-15...

> Да. Но знаете ли, не все считают хорошей идеей каждые полгода форкать
> testing и отдельно поддерживать. Сизифов труд, чесслово.

Это не столько "форк", сколько "фаза стабилизации". Дебиан делает то же самое, но - раз в два года. Но для меня раз в 2 года - слишком медленно, я считаю софт 2-летней давности тухляком.

> Ой, ладно Вам, какой там "высший пилотаж". Это так нынче называется "перейти
> на testing"? )

Да, потому что будут или массовые факапы, если софт подтягивать весь - все-время будут какие-то fallouts (вплоть до неработоспособности бутлоадера!!!), или придется в ручном режиме тыкать пакетный менеджер в конкретные версии пакетов там и тут. Стабилизации (даже сравнимой с убунтуйской полугодичной) при этом нет даже в проекте и поэтому вся система превращается в минное поле. Мне не надо десктоп который может развалиться в ответственный момент.

Ответить | Правка | Наверх | Cообщить модератору

251. "Релиз Debian 8.0 Jessie"  –2 +/
Сообщение от freehckemail (ok), 27-Апр-15, 23:03 
>> А попробуйте ответить на банальный вопрос: какие-такие новые версии софта Вам нужны, и зачем?
> Linux kernel. Потому что я не некрофил и у меня бывает достаточно
> свежее железо. К тому же мне нравятся возможности btrfs и я
> им, натурально, пользуюсь.

Ну, про btrfs не знаю. Мне за глаза хватает обычного LVM. К тому же, я слышал, что btrfs ещё не очень стабильна. Может, ошибаюсь, конечно, но у меня всё прекрасно работает на связке lvm2+reiserfs+ext4.

> MESA - затем что каждая новая версия работает лучше старой и мне
> не хочется связываться с блободрайверами и их проблемами.

Простите, но это блажь. Вы либо пользуйтес DE с неадекватными разработчиками, завязывающимися на видео слишком сильно, либо в игрушки чрезмерно гоняете. Других причин так жаждить новый Mesa я не вижу. Не для работы же в самом деле.

> KiCad - потому что мне пригодятся новые фичи.
> Nginx - same.
> Geany - аналогично.

Backports?

> ffmpeg/libvpx/libav - потому что я хочу поддержку VP9.

Debian-multimedia repo?

> XFCE 4.12 - имеет ряд улучшений относительно старых версий. Не критично но
> приятно.
>> Да. Но знаете ли, не все считают хорошей идеей каждые полгода форкать
>> testing и отдельно поддерживать. Сизифов труд, чесслово.
> Это не столько "форк", сколько "фаза стабилизации". Дебиан делает то же самое,
> но - раз в два года.

Угу. То-то в этой фазе стабилизации всё так же разносит, как и в Testing.

>> Ой, ладно Вам, какой там "высший пилотаж". Это так нынче называется "перейти
>> на testing"? )
> Да, потому что будут или массовые факапы, если софт подтягивать весь -
> все-время будут какие-то fallouts (вплоть до неработоспособности бутлоадера!!!), или
> придется в ручном режиме тыкать пакетный менеджер в конкретные версии пакетов
> там и тут.

Вы собираетесь сейчас сказать мне в лицо не моргнув даже, что в промежуточных релизах Ubuntu это не так? =)

> Мне не надо десктоп который может развалиться в ответственный момент.

И поэтому Вы пользуетесь Ubuntu? =)

Послушайте, это уже комедия. Я сдаюсь, я проиграл. Вы правы, Вы победитель. Давайте на этой доброй ноте и разойдёмся. )

Ответить | Правка | Наверх | Cообщить модератору

287. "Релиз Debian 8.0 Jessie"  +/
Сообщение от Аноним (-), 29-Апр-15, 21:10 
> Ну, про btrfs не знаю. Мне за глаза хватает обычного LVM.

У btrfs все сильно лучше со снапшотами, которые являются логичной фичой для CoW-based ФС. Снапшоты штука удобная, что ни говори. Даже если продолбаться и стереть/перезаписать/... нужные файлы, можно быстренько вернуть как было и попробовать еще раз.

На виртуалках состояние машины можно заснапшотить ... ну более десятка лет - точно. Наверное даже больше. Это очень удобно. И результативно. Можно опробовать нечто, а если результат не понравился - отмотать на снапшот. Сильно быстрее чем раскатывание бэкапа или реинсталл.

> К тому же, я слышал, что btrfs ещё не очень стабильна. Может,
> ошибаюсь, конечно, но у меня всё прекрасно работает на связке lvm2+reiserfs+ext4.

Мнение пользователя рейзера о стабильности файлух - это как мнение камикадзе о надежности самолетов. Рейзер умрет если просто положить на него файл виртуалки с рейзером. При очередном запуске fsck рейзера на хосте - просто разнесет том в вермишель. Это у них "known issue" такой. С воркэраундом "не храните файлы с reiserfs на диске с reiserfs". А то видите ли, fsck рейзера может чужое дерево в файлуху раскатать. По поводу чего виртуалки на рейзер класть очень рисково. И вообще, fsck рейзера - отличный тул для раздачи врагам.

> Простите, но это блажь. Вы либо пользуйтес DE с неадекватными разработчиками,
> завязывающимися на видео слишком сильно, либо в игрушки чрезмерно гоняете.

А также хочу видеть трехмерные панорамы в гугле и прочая. И чтобы GPU при этом не падал. И видео смотреть. На большом мониторе. Без тиринга. А в идеале - и с аппаратным ускорением.

А если сидеть только в сpaной консоли 80х25 - так это, времена MSDOS-а слегонца закончились и нынче немного иные требования к компьютерам. И я бы не хотел рассказывать хомякам почему винда может им показать панорамы в гугле, а пингвин - нет.

> Других причин так жаждить новый Mesa я не вижу. Не для работы же в самом деле.

GPGPU как таковой набирает обороты и находит самые разные применения. И да, немного поиграть - а почему бы и нет? Нынче даже в процы GPU интегрирован.

> Backports?

А когда мне понадобится очередная софтина - заметить что ее там нет. Очень удобно.

> Debian-multimedia repo?

Да, да, даешь ручного управления и побольше. Понятно что можно костылировать до упора из принципа. Но порой взять свежевышедшую убунту оказывается проще...

> Угу. То-то в этой фазе стабилизации всё так же разносит, как и в Testing.

В testing могут без предупреждения подкинуть софт в версиях по крупному, а в убунте между релизами - такое не практикуется. Ну кроме разве что браузеров, сватать браузер укушенный стабилизцом - очень уж чревато и безответственно в плане уязвимостей.

> Вы собираетесь сейчас сказать мне в лицо не моргнув даже, что в
> промежуточных релизах Ubuntu это не так? =)

Конечно. Там версии по крупному не подтягивают между релизами. Фаллауты в основном бывают при апгрейде с версии на версию, но когда это будет происходить заранее известно и можно выбрать момент когда фаллаут не ведет к завалу каких-то ответственных задач.

>> Мне не надо десктоп который может развалиться в ответственный момент.
> И поэтому Вы пользуетесь Ubuntu? =)

Внезапно, да.

> Послушайте, это уже комедия. Я сдаюсь, я проиграл.

Да, это - комедия. Фанат-зилот лечит профессионала по качеству, который себе на хлебушек зарабатывает как раз компетенцией в вопросах качества... про качество. Такая прыть зилота - невозбранно доставляет.

> Вы правы, Вы победитель. Давайте на этой доброй ноте и разойдёмся. )

Давайте. А то вы меня перекормите лулзами. И ваш уровень компетенции станет всем более очевиден.

Ответить | Правка | Наверх | Cообщить модератору

158. "Релиз Debian 8.0 Jessie"  +2 +/
Сообщение от Аноним (-), 27-Апр-15, 05:37 
ниразу не интересный баланс, ставить промежуточные между lts релизы вечно что-то падает.
сидеть на ubuntu lts и обновляться каждые два года - уже ни разу не удобно, можно ждать и больше, но совсем старье в системе будет, постоянно бояться что при апдейте не на lts что то отвалится - ну нафиг. проще сидеть тогда сразу на rolling release. например arch :-)

А у дебиана аналогов в чем нету? нацеленности на пользователя, на сервер, на эмбендед? или аналога все-в-одном-собери-как-надо?

Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

232. "Релиз Debian 8.0 Jessie"  +/
Сообщение от Аноним (-), 27-Апр-15, 20:02 
> ниразу не интересный баланс,

Вот лично мне он удобен и интересен -> поздравляю, гражданин соврамши.

> ставить промежуточные между lts релизы вечно что-то падает.

А в testing - намного более злобное минное поле. Где может загнуться все. Вплоть до бутлоадера.

> сидеть на ubuntu lts и обновляться каждые два года - уже ни разу не удобно,

Не более и не менее удобно чем на таком же по смыслу дебиане. А колупаться в архаичной версии софта 5-летней давности мне не доставляет. Потому что в каком-нибудь KiCad например за это время привинтили валидацию длины дорожек печатной платы для DRAM (что позволяет сделать более-менее серьезный девайс целиком в открытом софте, не получив по физиономии граблями лишний раз, что дорого и утомительно). Самому с микрометром это делать мне впадлу, извините. И компилить самому новую версию - впадлу. И даже пилотировать пакетный менеждер в режиме высшего пилотажа - неохота.

> то отвалится - ну нафиг. проще сидеть тогда сразу на rolling
> release. например arch :-)

Мне не надо rolling: мне нравится идея замораживать между релизами мажор версии софта, но тут возникает вопрос в частоте релизов. Для меня оптимум имхо полгода-год. А два - уже слишком медленно, софт становится слишком тухлым на мой вкус. Вот убунта именно это и имеет предложить, мне это нравится. А у дебианщиков подобных вариантов нету. У них можно выбирать между чем-то сравнимым с "LTS" убунты и камикадзингом в духе арча на тестинге. И все.

Я например нормально отношусь к systemd. Но нет, мне его не надо между релизами в непредсказуемый для меня момент времени. Я запланирую время для системокрушильных дел, удостоверившись что на этот момент нет никаких критичных мероприятий требующих этого компьютера в рабочем состоянии и вот тогда вкачу систему с системды и прочая. А в режиме как снег на голову - мне резкие изменения в системе не надо, спасибки. Поэтому арчеводы с их помиранием системы если ман на апдейты не почитать могут идти курить бамбук, мне система с такими свойствами не требуется. У меня на компьютеры завязаны достаточно критичные задачи, отвал которых может мне довольно дорого обойтись.

> А у дебиана аналогов в чем нету?

У них нет аналога не-LTS убунтов. Которая по смыслу как обычный дебиан, только с циклом релизов полгода вместо 2 лет. Что конечно же несколько снижает протестированность, но повышает свежесть софта. Но главное - как и в дебиане, никто не вкатывает ломающие изменения между релизами, как в тестингах и прочих арчах, так что если система заработала - то следующие полгода она скорее всего проработает без особых приключений. А вкатывание и прочая - происходит в известное окно времени которое можно без проблем разместить в интервале времени когда ничего важного не ожидается.

И нет, сколько какую-нибудь MESA 10.3 не тестируй, а MESA 10.5 - лучше. Но штатно получить свежие версии в дебиане опаньки, а услуги по "стабилизации" древнего тормозного глючного гуано мне не очень требуются.

> на эмбендед? или аналога все-в-одном-собери-как-надо?

Это еще можно пережить. Но для меня релиз раз в 2-3 года слишком медленно и тухлый софт мне не друг. А камикадзить на тестинге я не собираюсь, мне работающие компьютеры нужны.

Ну и куча мелких шероховатостей всех мастей. Какое-нибудь отсутствие фирмварей для беспроводки может и фича, если это у меня база для респина своего кастома. Но большой баг, если я пришел ставить систему хомяку, а у него только беспровдка и есть, так что добро пожаловать в pkunzip.zip.

Поэтому по совокупности параметров - лично мне убунтовые системы на десктопе как-то практичнее.

Ответить | Правка | Наверх | Cообщить модератору

240. "Релиз Debian 8.0 Jessie"  +1 +/
Сообщение от Michael Shigorinemail (ok), 27-Апр-15, 20:48 
> И компилить самому новую версию - впадлу.

Те, кому не впадлу, делают бэкпорты и разделяют такую цену своих хотелок между собой.

> Мне не надо rolling: мне нравится идея замораживать между релизами мажор версии
> софта, но тут возникает вопрос в частоте релизов. Для меня оптимум
> имхо полгода-год.

Это сузешный вариант.

> И нет, сколько какую-нибудь MESA 10.3 не тестируй, а MESA 10.5 - лучше.

Насколько понимаю, косвенной проблемой для бэкпорта на как раз двухлетнюю ветку может оказаться лишь старый llvm со своими сборочными зависимостями.  Т.е. mesa-то да, а вот с ним не помню.

> Это еще можно пережить. Но для меня релиз раз в 2-3 года
> слишком медленно и тухлый софт мне не друг. А камикадзить на
> тестинге я не собираюсь, мне работающие компьютеры нужны.

В "одном дистрибутиве" (tm) на сейчас выработалась промежуточная между "релиз плюс только точечные исправления" и "роллинг тестинг" модель: в стабильной ветке, на которой собираются обновлённые версии дистрибутива (как вот готовящиеся 7.0.5) и которая по умолчанию предлагается для забора обновлений, возможны и смены версий в разумном объёме.

Критерии недостаточно формализованы (и в части ABI этим рано или поздно придётся заняться), но на практике результат получается неплохой.

> Какое-нибудь отсутствие фирмварей для беспроводки может и фича, если это у меня база
> для респина своего кастома. Но большой баг, если я пришел ставить систему хомяку, а
> у него только беспровдка и есть, так что добро пожаловать в pkunzip.zip.

(воздевая руки) И эти люди будут попрекать A*T видеоблобами, которые тот якобы везде в дистрибутивы пихает!..

Кстати, вот так видели? :)  http://git.altlinux.org/people/mike/packages/?p=mkimage-prof...

Ответить | Правка | Наверх | Cообщить модератору

254. "Релиз Debian 8.0 Jessie"  –1 +/
Сообщение от Аноним (-), 27-Апр-15, 23:49 
> Те, кому не впадлу, делают бэкпорты и разделяют такую цену своих хотелок между собой.

Если честно, в глубине души я считаю бэкпортирование почти тождеством "работа на мусорный бак". Это дурная работа на ровном месте, за это же время можно было бы сделать что-то более полезное чем борьба с искусственно созданными административно-политическими трудностями. Поэтому я не фанат такого подхода.

И лично мне с технической точки зрения удобнее выкроить полдня в предсказуемом интервале времени и там подтянуть весь софт оптом, нежели колупаться с ручным управлением пакетным менеджером.

Вообще, пакетный менеджер на мое мнение хорош прежде всего тем что позволяет спихать кучу рутины на машину (ну и майнтайнеров, каждому понемногу). И я совсем не горю желанием отыграть это назад и создать себе какие-то дополнительные сложности на ровном месте.

> Это сузешный вариант.

Меня устраивают комьюнити сборки убунтов, по типу хубунты. Сами репы как база вроде нормальные, инсталляционная болванка - без эпикфэйлов, а больше мне от них ничего особо и не надо. А зюзя имеет проблемы с качеством - заходишь браузером дефолтной зюзи на опеннет, а там жесть вместо шрифтов. Я это сам дочинивать должен? Три раза пробовал, все три раза так было. На четвертый мне даже и пробовать такую систему уже не хочется.

> Насколько понимаю, косвенной проблемой для бэкпорта на как раз двухлетнюю ветку может
> оказаться лишь старый llvm со своими сборочными зависимостями.

При том - в LLVM до этак примерно 3.5 (включительно) на GCNах были довольно кусачие баги (хотя особенно злобно в 3.4 и ниже). Кроме всего прочего, оно могло генерить код, от которого GPU встает колом. Да и сама старая MESA порой делала в древних версиях какие-то вещи, вызывающие проблемы у GPU.

Очень мило когда юзерь запускает WebGL демку в браузере .. тынц .. что значит "no signal"?! Вот вам и стабильность "проверенного" софта...

Вообще, на мое нескромное мнение, ((MESA < 10.5) || (LLVM < 3.6)) && GCN) я бы просто в блеклист внес. В браузерах. Чтобы они даже не пытались WebGL через это рендерить - чревато брутальной ремотной DoS attack на драйвер видео, требующей перезагрузки системы "вслепую" или как минимум падением браузера по assert-у в LLVM (забавно когда "посторонняя" либа грубо выносит весь процесс).

> Т.е. mesa-то да, а вот с ним не помню.

Если мы о стабильности, чисто по человечески могу дать совет обладателям GCN-ов (а это почти все APU и GPU от амд за последние пару лет): лучше всего послать всех зилотов с их "стабильностью" и "протестированностью" и просто в принципе не рассматривать LLVM старее 3.6. И MESA 10.5 будет совсем не лишней. Вот это - то что должен принести с собой реально претендующий на десктоп дистр. А в новых иксах и DDX - здорово оптимизнули glamor, так что он местами раза в 2-3 быстрее стал. Уж наверное десктопному дистру ускорение графики лишним не бывает, или чего?

> В "одном дистрибутиве" (tm) на сейчас выработалась промежуточная между "релиз плюс только
> точечные исправления" и "роллинг тестинг" модель:

Это наверное не самый плохой вариант на свете, чем-то отдаленно напоминает то что в убунте. Ну то-есть я раз в полгода не против уделить время массовой подтяжке софта, но мне нужна более-менее стабильная система между перетрясами. А какие мне точечные фиксы нужны - я выбираю путем подключения PPA (ну или самоличной пересборкой, если интересно или сильно надо, а никто не сделал).

> Критерии недостаточно формализованы (и в части ABI этим рано или поздно придётся
> заняться), но на практике результат получается неплохой.

С abi на самом деле небольшие странности бывают и у дебианщиков/убунтуев. Ну то-есть бывает так что перестраивают либу типа openssl, которую использует множество софта. При этом некоторый софт уже стреляные воробьи и честно пишут warning про то что версия фактически доступной либы и хидера - разные.

> (воздевая руки) И эти люди будут попрекать A*T видеоблобами, которые тот якобы
> везде в дистрибутивы пихает!..

Ну во первых драйвер там открытый, но вот фирмваре может требоваться для работы чипа. А кому фирмваре в сервисных сопроцессорах не нравится - должны немедленно отцепить сидюки и флешки, жесткие диски, мониторы, клавиатуры, мыши, да в общем почти любую периферию.

Единственное отличие - что фирмварь некоторых wi-fi сетевок живет не в встроенной флехе а должна догружаться снаружи. Сервисный процессор один фиг есть и большой вопрос что хуже - явно об этом знать, видя его код, или нарваться на его работу тихой сапой. Особо рьяные зилоты как-то тактично обходят этот неудобный вопрос, который однако не делает фирмваре в каком-нибудь жестком диске более безопасным чем внешнее фирмваре.

Никогда не слышали про Equation group и их модуль инфекции HDD firmware? Обеспечивающий их западлостроению весьма незаурядный persistence. Местный Каспер это дело нашел. То что фирмвару менее заметно - ни разу не делает ее безопаснее и дружественнее.

Вот я и думаю - вы лихо передергиваете, или сторонник тактики страуса?

А со своей стороны имею заметить что для меня в общем случае деблоб основного процессора - первый приоритет, а сервисные сопроцессоры - все-таки второй и далее, в зависимости от того куда и что прицеплено. Хотя есть и принципиально недеблобизируемые и проблемные архитектуры, типа Qualcomm Snapdragon какого-нибудь, у которых проц с линем и есть на правах "сервисного сопроцессора" с функцией "отрисовка гуя к нашему модему".

> Кстати, вот так видели? :)  http://git.altlinux.org/people/mike/packages/?p=mkimage-prof...

Как интересно... а почему в этом файлике так мало беспроводок? Они где-то еще вписываются? Ну там ралинки - где? Юсб-девайсы всякие, им чуть ли не всем надо фирмварь: и ралинкам, и атеросам, и реалтекам всех мастей, насколько я помню (из того что более-менее массово продается). Там кстати у ath9k_htc фирмварь нынче опенсорсная, так что ее вскоре и щепетильные дебианщики должны бы подхватить. А кроме всего прочего, такая щепетильность - некий стимул остальным вендорам не жадничать. У QualcommAtheros появился такой вот небольшой козырь перед конкурентами. Жаль ath10k это пока не коснулось. Если что - я за открытие фирмварей. Но давайте без ханжества, двойных стандартов и заметания проблем под ковер? А в идеале еще и с разумной расстановкой приоритетов.

Ответить | Правка | Наверх | Cообщить модератору

256. "Релиз Debian 8.0 Jessie"  +1 +/
Сообщение от Michael Shigorinemail (ok), 28-Апр-15, 00:31 
> Если честно, в глубине души я считаю бэкпортирование почти тождеством
> "работа на мусорный бак". Это дурная работа на ровном месте

Погодите.  Известны такие подходы для решения задачи обеспечения доступности более-менее свежего пользовательского софта:
- "собери сам";
- "скинемся напильниками на бэкпорт";
- "роллинг";
- "частые релизы".

Порядок перечисления мало о чём говорит, т.к. плюсы и минусы вариантов можно расписывать отдельно и довольно подробно -- но мне, например, дурной работой на ровном месте уже много лет кажутся убунтушные "полугодовые релизы", причём цена этой марковой дури -- немалое количество *выгоревших* разработчиков Debian, имевших неосторожность пойти за этим человеком.

> за это же время можно было бы сделать что-то более полезное чем борьба
> с искусственно созданными административно-политическими трудностями.

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

> И лично мне с технической точки зрения удобнее выкроить полдня в предсказуемом
> интервале времени и там подтянуть весь софт оптом, нежели колупаться с
> ручным управлением пакетным менеджером.

А я вообще не мумукаюсь, т.к. у нас нет ни проблем testing (тем более unstable), ни проблем stable.  Есть другие, но выбор между теми и этими для меня оказался прост.

> [...GCN...] и просто в принципе не рассматривать LLVM старее 3.6

Да-да, эту рекомендацию ещё вчера заметил и спасибо.  Только там, по словам майнтейнера, не всё так гладко с обновлением (не помню детали).

> Никогда не слышали про Equation group и их модуль инфекции HDD firmware?

Краем уха слышал.

> Вот я и думаю - вы лихо передергиваете, или сторонник тактики страуса?

Съехидничал малость.

>> Кстати, вот так видели? :)  http://git.altlinux.org/people/mike/packages/?p=mkimage-prof...
> Как интересно... а почему в этом файлике так мало беспроводок?

В основном в firmware-linux, а это то, что отдельно (более новое или уже втянуто, но пока не убирал старое имя, чтоб не навредить на более старых ветках репозитория).  Кстати, обновил, наработали уже коммитов с декабря.

> Там кстати у ath9k_htc фирмварь нынче опенсорсная, так что ее вскоре
> и щепетильные дебианщики должны бы подхватить.

Эт хорошо ;-)

Ответить | Правка | Наверх | Cообщить модератору

269. "Релиз Debian 8.0 Jessie"  +/
Сообщение от Аноним (-), 28-Апр-15, 14:36 
> Порядок перечисления мало о чём говорит, т.к. плюсы и минусы вариантов можно
> расписывать отдельно и довольно подробно -- но мне, например, дурной работой
> на ровном месте уже много лет кажутся убунтушные "полугодовые релизы",

Со своей стороны могу констатировать, что эта идея и ее реализация тем не менее нашли немало поклоников.

> причём цена этой марковой дури -- немалое количество *выгоревших* разработчиков Debian,

Мне кажется проблема здорово преувеличена на почве конкурентских антипатий. Торвальдс вообще один релизит огроменный кернел, раз в 2-3 месяца, и так - много лет. Он, конечно, такой один. Но при 20М пользователей - из их числа по любому будет иногда находиться кто-то достаточно грамотный для того чтобы подхватывать знамя. Да и дебианщики часть работы делают. И я вижу некоторое количество кадров которые в проекте уже длительное время. В целом имхо механика работает. То что более короткий релиз имеет шансы быть более забагованым - да, имеет. Но т.к. политика версионирования между релизами дебианообразная, это лучше чем testing репы в дебиане по стабильности и предсказуемости. В том плане что между релизами у меня не помрет внезапно grub2 на том основании что модули и core сильно разъехались по версиям, и никто не припрет мне systemd при "просто апгрейде", без предупреждения и чего доброго что-нибудь сломав, на что выли любители тестинга, узнавшие наконец почему тестинг так называется.

> имевших неосторожность пойти за этим человеком.

По моему мнению - у людей должен быть выбор. И частые релизы одна из опций. Кто-то тянет такой темп, кто-то нет. Разработка софта - не выпас стада, ориентироваться на самых медленных овeц совершенно не обязательно. Кому хочется более скромный темп развития - есть хоть тот же дебиан (от существования которого выигрывают многие, в том числе и убунта). У людей был выбор. Они должны понимать на что шли и оценивать свои силы.

С другой стороны - бэкпортирование довольно бесполезная работа. Люди тратят время на борьбу с искусственными политическими ограничениями и потом на такой софт даже баг например апстриму особо не зарепортишь - мало ли что там поменяли и кто баг посадил. Если софт идет более-менее апстримно, с нулевыми или небольшими изменениями - баги или улучшения можно апстриму отдавать относительно малой кровью. Де факто я считаю что бэкпорты отвлекают толпу народа на непродуктивную в долговременном плане активность и клинят общее развитие софта.

Ну и кроме того - со своей стороны я в обещм случае не хочу тяжеловесный интрузив от майнтайнеров. Для меня майнтайнеры - лишь вратари которые должны ловить явные плюхи апстрима. Компетенция майнтайнеров в глубинном устройстве софтины - является весьма рандомной величиной, поэтому лучше всего если они будут только опакечивать и проверять что это заработало и донапиливать только абсолютно неизбежное, в минимальном объеме. Экономя силы себе и не создавая своей жизнедеятельностью искусственные сложности другим.

> Полностью ошибаетесь с характеристикой.  Конфликт здесь в том, что хочется обновлением
> платформы заниматься пореже (т.к. это морока и потеря времени),

С другой стороны - это ведет к застою и протуханию софта и core-части и клинит развитие софта, да и проекта в целом.

Ну понятно что альту с полутора землекопами на проект, где в пересчете на человека уйма работы - большой темп развития взять технически сложно. А Шатлворт принял иные решения и в конечном итоге получилось так, что он себе это может позволить. И это вроде работает. В силу толпы разработчиков знакомых с убунтой и базирования на дебиане, объем работ в пересчете на каждого конкретного индивида судя по всему не такой уж и огромный.

> а нужные кусочки прикладного софта и/или драйверов иметь посвежее
> (т.к. это нужная функциональность).

1) У ядра нет "кусочков" как таковых. Ну то-есть есть некие внутренние границы по подсистемам, но они больше для разработчиков и их процесса разработки. Для сборщика самый простой вариант менять все ядро целиком, все остальное - жуткий запрыг по костылям и уйма контрпродуктивной возни.
2) Вы никогда не угадаете какой именно свежий софт или компонент хочет конкретный юзер (например, я). Это означает что .. для того чтобы угодить всем, надо апдейтить все. И заявы про стабильность платформы стало быть идут лесом. Разработчики в массе своей например искренне ненавидят бодаться с багами древних либ, починеных в новых версиях. И поэтому имеют тенденцию не поддерживать откровенно тухлые компоненты в новых версиях. Подход такого плана интересует в основном всяких корпоративщиков. Ну да, там есть редхат. Они окучивают бизнес. Это сравнительно малочисленный, но высокодоходный рынок, которому чаще всего хватает ограниченного типового набора софта. Поэтому редхат не гоняется за поддержкой 100500 пакетов как дебиан и убунта. С другой стороны по этой причине они не конкурент Шатлворту на десктопе - general public редхаты с их приоритетами и полутора пакетами - малоинтересны.
3) Вот лично мне например удобнее подтягивать софт по версиям с риском отвала массово, в оговоренный интервал времени, а размазывая гемор и риски на весь срок эксплуатации. Для меня полдня концентрированного гемора и танцев с бубном на верификацию, а потом полгода более-менее предсказуемой и спокойной работы выглядят более интересной опцией чем лишняя возня с мануальщиной и повышенные риски по всему периоду эксплуатации.
4) Наверное логично, что я со своей стороны - за подходы которые мне оказываются удобны.

> А я вообще не мумукаюсь, т.к. у нас нет ни проблем testing
> (тем более unstable), ни проблем stable.  

Это всего лишь потому что мумукание размазано во времени и менее заметно на первый взгляд. Поскольку в целом процесс более-менее эквивалентен (я или уж получаю свежую версию энного компонента или уж нет), вся разница - лишь в формате подачи. Ну то-есть вкатывая более новую версию из бэкпорта я буду валидировать ее поведение и нести риски что что-то сломается. Просто это окажется размазано по времени на весь срок эксплуатации вместо того чтобы размахаться сразу с кипой софта за полдня и забыть про все это на полгода.

> Есть другие, но выбор между теми и этими для меня оказался прост.

Ну а мой выбор вот такой. Меня он устраивает. Иначе он, очевидно, был бы другим. Правда жизни такова что я вообще не люблю тухляк в либах, ядрахи прочем, но не собираюсь заниматься ультра-камикадзинком по типу роллинга.

> Да-да, эту рекомендацию ещё вчера заметил и спасибо.  Только там, по
> словам майнтейнера, не всё так гладко с обновлением (не помню детали).

Могу предположить что проблема в том что завязка на LLVM. Иногда бывает так что фича превращается в баг. И это именно тот случай - code reuse это здорово. Но есть нюансы. LLVM как бы довольно системная штука. И вот так наобум его подкинуть в версии на 1-2 major релиза - эм, у юзера могут быть тулчайны на его основе, их тоже надо подтягивать. И вообще надо пересобирать то что LLVM юзало. Если об этом не подумать заранее - может получиться немало грабель. А если юзер какой-то кастомный тулчейн собрал... ну... его придется еще раз собирать. Или как-то утрясать жизнь нескольких версий либ в системе и чтобы остальная механика и майнтайнеры на это не смотрели волком. В общем в живой стабильной системе такой пируэт действительно может быть нетривиален и граблеопасен.

...в этом месте мы начинаем догадываться что "частые релизы" здорово уменьшают эту проблему ;). А подобный класс проблем - он характерен далеко не только для LLVM.

Подтянуть версии тех или иных либ может хотеться по куче причин. Но это далеко не всегда просто сделать. Поэтому долговременная платформа может начать клинить уйму всего, на бэкпорты начнет уходить дофига усилий, которые в глобальном масштабе есть работа на мусорный бак: при обновлении платформы эти усилия будут во многом аннулированы.

> Краем уха слышал.

Ну вот там можно увидеть пример недружественного поведения фирмвары. Одного из. Если быть пессимистом - можно ожидать что фирмварь сможет запатчить операционку при загрузке.

> Съехидничал малость.

"Над кем смеетесь?". Проблема с блоботой в фирмварах - у нас всех. И если вы еще не поняли насколько большой залет у нас по этой линии намечается: http://auto.onliner.by/2015/04/27/auto-11/  (ума не приложу - попадает ли это оборзение под тематику опеннета и стоит ли сюда новость постануть).

> В основном в firmware-linux, а это то, что отдельно

А, то-то я смотрю - какие-то довольно экзотичные сетевухи.

> Эт хорошо ;-)

Со своей стороны я разумеется приветствую такие инициативы и искренне желаю остальным производителям последовать примеру. Жаль что до идеала как до луны, а встроенные фирмвары открывать и вовсе стимула мало. Зато западлостроения - много. В стандарте BlueRay например диск (а точнее софт на нем) может совершенно официально убить привод, если посчитает что прошивка привода хакнутая и не соблюдает DRM. Впрочем, это еще цветочки, ягодки вон General Motors готовит...

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру