Pull to refresh

Comments 51

Как я понимаю, автор хотел сказать, что все мы знаем про OpenSource, но для многих он как млечный путь — он есть, но где-то далеко нереально к нему прикоснуться. А все на самом деле проще и ближе!

P.S. Немного напоминает статью про первый секс с Linux =)

Вам повезло. Обычно нужно пройти семь кругов ада для того, чтобы реально нужные изменения попали в репозиторий. Посмотрите хотя бы сколько репов на launchpad с какими-нибудь фиксами. У меня на HTPC материнка с APU AMD E350. Я купил ее сразу после выхода и до сих пор (уже наверное года 2) мне приходится пол-системы (Ubuntu 12.10) устанавливать с launchpad чтобы все работало как надо.
Я помню, как я сражался почти полгода за то, чтобы usb_modeswitch включили в дефолтную поставку sid. Было весело.
Видимо надо чтобы кто-нибудь провел эти пакеты через процедуру Stable Release Updates.
Может быть Вам попробовать?
Как и многим, мне мешает отсутствие свободного времени и (увы) собственная лень.
Ну вот видите, автор не поленился и таки нашел нужных людей. Мне кажется тут скорее надо не самому пытаться брать на себя обязательства, а найти человека, который уже имеет обязанности позволяющие добавить пакет хоть и через других людей.
Если на хабре найдется человек, который сможет стать моим наставником (mentor) и в перспективе адвокатом в становлении debian maintainer, я буду очень рад.


Я сам гентушник, но мне кажется, что сначала Вы должны поставить себе дебиан.

Вообще самое первое и простое, что может сделать пользователь любого дистрибутива — это не проходить мимо проблем, а сообщать о них разработчикам через багзиллы и иже с ними. Только не в стиле «Ааааа, ни работает, почините!», а так как просят разрабы, обычно это указание версии пакета, где есть проблема, описание проблемы, вывод команды с информацией о системе аля emerge --info.

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

Потом собирать пакеты.

Потом писать патчи.

Потом собрать дистрибутив.

Потом полететь в космос.

PROFIT :-D
Мне кажется этот путь проходят все вменяемые линуксоиды со стажем использования системы более пары лет
Далеко не все. Я так давно и стабильно застрял на первом пункте.
Совет постить в багтрекер дистрибутива имеет смысл далеко не для «любого дистрибутива». Это в Debian патчить всё и вся — нормальная практика. А там, например, в ArchLinux, могу сказать по собственному опыту, даже если Вы распишите всё в подробностях и приаттачите suggested patch, Вам в 90% отпишутся, что проблема отностится не к дистрибутиву и предложат написать разработчику. Т.о. лучше не тратить лишнее время, а сразу постить в mainstream. А багтрекер дистрибутива оставить на крайний случай, если mainstream уж совсем отмороженный. Ну или на случаи, когда явный баг мейнтейнера, а не разработчика.
Не пользовался Arch Linux, но в «страшной», «красноглазой» генте в худшем случае, не закрывая баг в своей багзилле, попросили бы открыть баг в апстриме, подсказав где именно и ссылку добавить в описание бага в гентушной.

Ну и очевидно баг в апстриме скорее будет пофикшен. Правда не всегда удается точно понять что же это блин глючит. И вот тут мейнтейнеры дистра помогают, потом уже приходит свой опыт.
Тут еще логика заключается в том, что при фиксе в upstream фикс появится во всех дистрибутивах со временем, а не только в том, в котором заметили.
В дистрибутиве принято исправлять только те части пакета, которые специфичны для этого дистрибутива.
Вопрос в том, кто этим занимается.
Ну логично что, maintainer:
1. В случае особенностей дистрибутива, правит пакет.
2. В случае ошибки в программе, mainteiner создает issue в upsteam.
Во втором случае может как создать сам, так и «отфутболить» туда. Зависит как от общей политики дистра, так и от конкретного человека.
Кто отфутболить? Если maintainer, то не совсем, так как на его имя в системе bug трекинга дистрибутива вешается баг и он должен что-то предпринять. Иначе можно ставить вопрос о смене мейнтейнера пакета.
Поставит стаус «баг апстрима» или типа того.
Идите в мир Archlinux'а — там комьюнити заметно демократичнее (на моём опыте, в багтрекере быстро отвечают, предложенные патчи быстро попадают в test-репозитории), плюс свои пакеты можно самостоятельно заливать на AUR, чтобы после проверки быть доступным всем пользователям. Из-за этого на моём опыте подобные проблемы с неочевидными зависимостями от ядра решаются гораздо раньше.
«Идите в мир CentOS — там вы вряд ли дождетесь патча, но зато всё, что работает — работает правильно».
Шутка, конечно.
На самом деле в какой мир идти — зависит от того, какое соотношение «свежесть/стабильность» вам нужно.
Далеко не только от этого зависит. Дистрибутивы не только по параметру свежесть/стабильность отличаются.
Различаются они кучей параметров.
Но когда приходит час Ч (выбрать себе mainstream дистрибутив для ...) — то приходится решать именно эту задачу — надежность vs свежесть.
Со всем, что из этих вещей проистекает. И от чего они зависят.
Параметром вполне может быть поддерживаемые DE. Какой дистр нормально поддерживает Unity?
В одном случае параметром может быть даже пакета какой-то специфичной софтины или редкостной железки.
Я говорю о своем mainstream — т.е. то, что будешь не раз ставить живым людям, изучать это, знать это.

Насчет Unity ничего сказать не могу — не пользуюсь. Даже не видел никогда.
Я как бы придерживаюсь «тактики» ставить людям то, что сам активно использую. А если они просят поставить что-то другое, то предупреждаешь, что помочь им если что оперативно не сможешь. А лично для меня нормальная поддержка Unity в дистре — определяющий фактор для личного повседневного использования в работе и для развлечений.
Я об том же — ставить надо то, что себе.
Другой вопрос — себе-то что ставить :-)

Но это уже каждый решается для себя сам.
Убедили — параметры выбора — субъективны.
Для меня это — надежность vs свежесть.
Для Вас — Unity или не Unity.
Вообще говоря даже надёжность и свежесть субъективны. В смысле за 3 года использования Арча на нескольких компьютерах (небольшой сервер, ноут — для всего включая медиа, жирная рабочая станция) с проблемами от ненадёжности софта из-за свежести (вида недостаточно протестировано) так и не встретился. Тогда как проблем вида «эта фигня не поддерживается в ядре/в несвежем модуле видеокарты» — довольно много.
И снова в точку.
(а на хабре нельзя писать иного — заминусуют, и тогда уже вообще ничего не напишешь :-).
Мы не будем разводить флейм «этот Linux vs другой Linux». Или «кеды против гнома».
Вы правы в том, что понятие «надежность» и «свежесть» — тоже субъективны.
Я — когда выбирал, куда сползти с одного широко известстного в узких кругах отечественного дистрибутива — действительно нарисовал себе планчик-конспектик — требования, их критичность лично для меня (точнее — для моих доходов), куда это можно запихнуть, куда — не можно, поддержка и т.д.

Поэтому каждый выбирает свои дистрибутивы исходя из… ну да — своих личных побуждений ;-)
Убедили — параметры выбора — субъективны.


Плюсую к этому. Я выбрал генту даже не за свежесть входящих в нее пакетов. stable ветка по некоторым пакетам отстает от Федоры или ОпенСуси. Я выбирал по гибкости и похожести на привычную мне слакварю и фрибзд.
А вот и еще один критерий — степень автоматизации.
Судя по всему — Вам комфортнее в системах «ручной работы» (BSD/Slak/source-based).
Мне комфортнее в «полу-автоматах» (хотя степень «атоматизации» определить довольно сложно).
А кому-то больше нравится максимальная автоматизация (и здесь уже меняют ОС).
Написать бы, как это всё происходит в Fedora (и/или вообще в rpm-based) — но и так минусов дочерта…
Хотя в общем и целом — примерно так же.
Не без своих приколов, ессно.
Пробовал пройти подобный путь, чтобы решить проблемы драйверов тюнера (входит в список официально поддерживаемых, но моя ревизия отказывалась работать), связывался с разработчиками, разбирал тюнер (включая ВЧ-модуль), чтобы определить чипы, методом научного тыка подставлял параметры от других схожих по начинке тюнеров, добился что tvtime нормально показывает картинку, но не может включить звук. Когда речь дошла до того, что снифать usb-трафик под виндой и линуксом, а потом их сравнивать, то я сдался и купил другой тюнер :(
> методом научного тыка подставлял параметры от других схожих по начинке тюнеров

А можно чуть подробнее?
Есть Си-структуры описывающие тот или иной тюнер, в частности через константы, описывающие его железную начинку (названия чипов грубо говоря), плюс какие-то константы (когда с мнемоническими именами через #DEFINE, когда захардкоженные) определяющие, видимо, параметры инициализации. Тюнера с точно таким набором чипов не нашел и стал подставлять константы (и типа чипов, и параметров) от разных, сначала точно такие, потом других версий, потом уже позже вообще грубый брутфорс по всем. Вставишь, скомпилируешь, выгрузишь старую версию модуля, загрузишь новую (иногда приходилось перезагружать ось) и так много-много раз, пока не надоест. Самое обидное, что понимал что буквально несколько байт не хватает, который драйвер не шлет тюнеру (скорее всего шлёт, но немного не те), потому что если включить тюнер в винде, потом выключить комп (из розетки или выключателем сзади БП, чтобы не послал reset тюнеру), включить и загрузиться в лине, то всё работает идеально, звуком можно управлять, он переключается вместе с ТВ каналами и т. п.
Я уж молчу про GDI-принтеры :-)
Мне кажется почти каждый занимался секасом с линуксом из-за какой нить железяки. Я вот мучался с тач экраном на старом ноуте.
но зачем?

Windows + VirtualBox + Debian.

На новом рабочем ноуте стояла восьмёрка, как-то до этого я, как линуксоид, с ней особо дела не имел — решил посмотреть, прежде чем сносить. Поигрался в неё 5 минут, после этого в момент уничтожения инсталлятором убунты таблицы разделов ощущения были, как будто уделал вампира осиновым колом.
Недавно помог разработчикам apache httpd найти и исправить баг PR#53963, добавленный исправлением другого бага в версии 2.2.23, за день до выхода релиза 2.2.24 :) Мелочь (ломавшая, кстати, rewritebase у mod_rewrite в субдиректориях), а приятно.
Побольше бы таких success story, желательно даже от менее крупных проектов (всё-такие контрибьютить Linux довольно непростая задача). Больше бы новичков подтягивалось, например, если рассказывали о каком-то проекте о том, что интересного для него надо/можно сделать и к кому обратиться (менторы и т.д.) — хотя я конечно понимаю, что искать это всё должен в первую очередь разработчик (как в Вашем примере).
Я блин такие дущещипательные хистори и на винде раз в неделю испытываю на работе (я уж молчу про многие кряки для игр. они ставятся людьми с инструкциями на 8 страницах.). К чему статья то? Заработать побольше лайков и плюсиков??? Афтор считает что его трогательное рукоблудие соподвигнет геймеров кинуться ставить убунту??? Объясните мне смысл статьи пж.

Может написать статью про солярку и секс с ней? Многие кинуться на нее перейти???? Линуксоиды были всегда по ущербны. У них комплекс неполноценности. Типо нас так мало и нужно тянуть в это болото еще людей, ибо будет не так мало и не таким ущербным ся будешь чувствовать. Есть конечно люди которые выбрали ее и идут с ней по жизни. а вот все остальное племя из разряда баранов. Для фона так сказать.
Вы коммитите в Windows каждую неделю?
Краткое содержание вашего комментария: «Ко-ко-ко-ко-ко!»
— Смысл статьи вполне очевиден из заголовка.
— Причём тут геймеры, не понял.
— К чему ваши брызги слюной насчёт заманивания в «болото»? Статья написана линуксоидом для линуксоидов.

Вообще, если ваша цель — не навалить кучу посреди комментов, а добиться того, чтобы к вам прислушались, перво-наперво перестаньте использовать лишние вопросительные знаки. Это выглядит безграмотно и излишне эмоционально (почти на уровне психоза).
Кстати после прочтения зашёл на сайт debian(ведь его я собираюсь в течении 2х недель поставить)
Действительно, там много пакетов требующих работы:
Ссылка
В этом посте очень не хватает ссылки на русскую версию руководства разработчика Ubuntu, где подробно описаны как процессы как собственно сборки пакетов, так и работы с инфраструктурой и взаимодействия в сообществе.
Кстати, если что-то непонятно, то не стесняйтесь писать на (мой хабраник)@(ubuntu.com).
Вам ещё много предстоит узнать, например о том, что есть пакеты, а есть ядро, и что драйвера могут быть и там и сям. Если действительно хотели помочь, и сразу всем пользователям ядра Linux, а не одной конкретной ветки дистрибутивов, нужно было посылать свой патч вот в этот код вот сюда.
Я понимаю что есть пакеты и что есть ядро :) Не первые года за Linux :)
Ядро наоборот осознано выпилило эти define.
Что помочь всем дистрибутивам, я отправлял патч авторам модуля в RealTek, в пакете используется именно их код. Но они не ответили.
Можно просто денег дать. Баксов 50 или 100 или даже 1000 — никто не откажется. А время потратить на основную работу или свои проекты. Денег вам это больше принесет.

Сам спонсировал FreeType и еще несколько проектов. Со следующей ЗП скину LibJPEG-Turbo.
Sign up to leave a comment.

Articles