Отчёт о состоянии разработки Devuan

Передайте пацанам, что udev тоже отвязан, а eudev является его слегка ухудшенной копией.

To make it 100% clear: Photoshop does not and will not rely on Windows. However, we do rely on certain APIs. Those APIs can be implemented by other components. Another message will follow which expands on this.

Так оно и есть. Собственно, некоторые версии фотошопа вполне работают в wine. А вино и есть альтернативная реализация windows API.

Передайте пацанам, что udev тоже отвязан

Не слежу за новостями, но есть подозрение, что не совсем так
Udev becomes systemd-only

Это дело будущего. Сначала kdbus появится в основной ветке ядра, потом в одной из следующих версий systemd появится опциональный вариант использования kdbus вместо dbus, только потом в одной из следующих будет убрана поддержка традиционного dbus. Gentoo stable, с учётом отставания от апстрима, это дай бог через год затронет, а то и через два. И это будет смертью eudev, потому что всё, что они последние два года делают — это мержат патчи из udev'а, а если мержить станет неоткуда, то …

история ffmpeg говорит что будут проблемы нерешаемые в рамках debian. а история systemd «разработки» учит тому что леннарт будет специально менять все что можно что бы затруднить существание альтернатив. или ктото мне может показать документированный и замороженный api от леннарта ?

история systemd «разработки» учит тому что леннарт будет специально менять все что можно что бы затруднить существание альтернатив

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

или ктото мне может показать документированный и замороженный api от леннарта ?

Да пожалуйста.

http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabi...

история ffmpeg говорит что будут проблемы нерешаемые в рамках debian

За разработкой ffmpeg не слежу, но разве это не означает, что ответственному за создание проблем мейнту нужно просто надавать по шапке?

eudev является его слегка ухудшенной копией.

Угу-угу, канешна. Когда этот чудак Поттеринг отломал работу на неюникодных локалях в udev(потому что «так надо») и отказался это чинить, то конечно, чуваки из eudev, которые откатили этот коммит нахрен а потом сделали правильный фикс делают что-то не то, да-да-да

У меня есть инсталляция генты с uclibc, локаль - C, я был очень удивлен что udev не собирается с USE="-nls" и при этом требует юникодную локаль. Сейчас уже вроде как пофиксили, хотя я не проверял - просто свалил с udev на eudev там, где udev тупо отказался собираться

Но это не отменяет того факта, что пока(см. тему выше) udev можно собрать без systemd

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

Фундаментальные проблемы линукса может исправить только установка Windows.

стабильный и документированный? это вот чтоли : _packed_ struct Header { uint8_t signature[8]; /* «LPKSHHRH» */ le32_t compatible_flags; le32_t incompatible_flags; uint8_t state; uint8_t reserved[7]; sd_id128_t file_id; sd_id128_t machine_id; sd_id128_t boot_id; /* last writer */ sd_id128_t seqnum_id; le64_t header_size; le64_t arena_size; le64_t data_hash_table_offset; le64_t data_hash_table_size; le64_t field_hash_table_offset; le64_t field_hash_table_size; le64_t tail_object_offset; le64_t n_objects; le64_t n_entries; le64_t tail_entry_seqnum; le64_t head_entry_seqnum; le64_t entry_array_offset; le64_t head_entry_realtime; le64_t tail_entry_realtime; le64_t tail_entry_monotonic; /* Added in 187 */ le64_t n_data; le64_t n_fields; /* Added in 189 */ le64_t n_tags; le64_t n_entry_arrays; }; документированно и стабильно?

делают что-то не то

А они в апстрим отправили этот «правильный» фикс?

Передумают, удалят systemd

Что может быть смешнее влажных мечтаний квазарчика? Только его баттхёрт - пиши ещё :-D

Да и да.

Да, через Kay Sievers вроде, обходным путем, Lennart баг закрыл как WONTFIX

А что за баг? Может, он и вправду WONTFIX, и фиксить нужно в другом месте?

Щаз сходу нагуглить не могу, как доберусь до гентушного CVS-а - посмотрю, там вроде vapier писал фикс на это, ссылка на баг в апстриме прилагалась.

Краткая суть - Леннарт заюзал функции, которые не дружат с не-UTF-8 локалями не обрамив их в соответствующие ifdef-ы(которые как бы есть)

Было это в районе udev-212, точнее уже не вспомню, надо смотреть логи CVS-а

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

Эпопею с опцией ядра 'debug' вспомни...

Эпопею с опцией ядра 'debug' вспомни

Насколько могу вспомнить, проблема в том, что они слишком много писали в /dev/kmsg, от чего ядро охреневало. И, насколько могу видеть в дереве исходников ядра, в документации не сказано, в каких количествах можно писать в kmsg...

Это я к тому, что их можно понять. Ничего a priori неправильного они не сделали, а дальше уже детали реализации. Или я не прав?

И, насколько могу видеть в дереве исходников ядра, в документации не сказано, в каких количествах можно писать в kmsg...
Или я не прав?

А еще в документации сказано что опция 'debug' предназначена для отладки ядра. И вешать сюда же опцию отладки systemd - это неправильно.

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

Как обычно - как выбирают «не xfce» например. Или тебя ещё и apt научить пользоваться?

Так нельзя же, разработчики пакетов впадают в истерию и пишут иниты для systemd? Они же уже выбрали.

Photoshop does not and will not rely on Windows. However, we do rely on certain APIs

Так оно и есть.

Не так. Photoshop поставляется в бинарных сборках. Как следствие он завязан на abi, а не только на api и на загрузчик, в elf его не превратишь. Ну и реестр винды тоже не совсем api, права на файлы, пути и т.п.

Короче аналогия говно.

Вот достаточно полный список.

на неюникодных локалях

За неюникодные локали в 21 веке нужно кастрировать ножницами. Уроды которые до сих пор используют восьмибитные кодировки должны умереть в адских мучениях!

Кастрировать ножницами нужно разработчиков системд, ибо писать софт ещё не научились, а уже в апстрим лезут.

Вот достаточно полный список.

Ахаха. Известный ЛОР-нытик Бирди выходит на международный уровень!

Когда этот чудак Поттеринг отломал работу на неюникодных локалях в udev(потому что «так надо») и отказался это чинить, то конечно, чуваки из eudev, которые откатили этот коммит нахрен а потом сделали правильный фикс делают что-то не то, да-да-да

Не нашёл упоминаний об этом ни в ченджлогах ни в заголовках коммитов на гитах обоих проектов. Точную ссылку можно на оба коммита?

Но когда поднялся аццкий вой

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

Обычное дело в разработке systemd - пока кто-нибудь резко не скажет апстриму что они удоды, когда они делают что-то не то - дело с мертвой точки не сдвинется

Ну-ну, то-то в sys-apps/systemd/files нет ни одного патча не из апстрима, все что были уже в апстрим приняты безо всяких резких заявлений.

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

Если проблема тебя не затронула - это не значит что её не было

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

А ты зайди как-нибудь на канал #systemd, когда Michal Gorny и Mike Gilbert будут изливать тонны желчи и бросаться ссылками на фиксы(которые таки будут приняты).

Почему не через багзиллу? Да потому что багзилла systemd в большинстве серьезных случаев настолько же нужна, как и багзилла ядра. В случае ядра всё решается через мэйллисты, в случае systemd - через IRC, на канале или в привате.

Открытая разработка в обоих случаях, во все поля...

За неюникодные локали в 21 веке нужно кастрировать ножницами

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

https://bugs.gentoo.org/show_bug.cgi?id=443028
http://cgit.freedesktop.org/systemd/systemd/commit/?id=2f96919bcdd0978164c

Пока нашел вот это, но это немного не о том - это косяк с требованием gettext/intltool при --disable-nls

В ChangeLog в генте на udev есть вот такая строчка:

  28 Mar 2014; Samuli Suominen <ssuominen@gentoo.org> udev-212-r1.ebuild:
  Fix building with uClibc and missing (or incompatible) locale_t, thanks to
  Mike Frysinger for helping with the patch.

А вот и история факапа, уже после отлупа патча в багзилле: http://lists.freedesktop.org/archives/systemd-devel/2014-April/018503.html

Перл оттуда:

systemd requires glibc, this is known and clear since the beginning.

glibc

embedded

Как я уже говорил - пусть либо крестик наденут(поддерживают embedded), либо трусы снимут(не говорят, что поддерживают embedded, игнорируя libc, использующиеся в embedded)

Если проблема тебя не затронула - это не значит что её не было

Я где-то говорил, что проблемы не было? «Адский вой» подразумевает, что с проблемой столкнулось достаточное количество людей, чтоб о проблеме услышали даже те, кого она не затронула.

А ты зайди как-нибудь на канал #systemd, когда Michal Gorny и Mike Gilbert будут изливать тонны желчи и бросаться ссылками на фиксы(которые таки будут приняты).

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

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

Ссылку на мэйллист я выше привел, наслаждайся

Я где-то говорил, что проблемы не было? «Адский вой» подразумевает, что с проблемой столкнулось достаточное количество людей, чтоб о проблеме услышали даже те, кого она не затронула.

Ты эмбедщик? Есть девайсы на uClibc с udev(да, бывают случаи когда mdev или static dev nodes недостаточно)? А таких людей много - и именно они подняли вой

Это как отломать поддержку какой-нибудь архитектуры(arm например), например. Пока у тебя нет этой архитектуры - тебе плевать. А адский вой владельцев подобных девайсов - будет, но пройдет мимо тебя.

Не ножницами, а тупым и ржавым, как неюникодные локали, полотном от ножовки.

Ну, для мелкого embedded - системд жирноват.
Однако кассовые терминалы, которые сейчас под икспей - тоже embedded. И туда и юникод, и glibc лезет нормально.

Однако кассовые терминалы, которые сейчас под икспей - тоже embedded.

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

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

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

Cubieboard - ембедед? Там тоже юникод и glibc нормально себя чувствуют. И кстати, на этом арме у меня системд нормально работает. К вопросу о кроссплатформенности.

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

Ну таки да.

Cubieboard - ембедед?

Нет. Ты бы ещё десктопный комп предложил ембедедом называть.

Нет. Ты бы ещё десктопный комп предложил ембедедом называть.

Те, ембедед у нас все, в чем микруха от калькулятора, не взирая на роль, которую железка выполняет?

Те, ембедед у нас все, в чем микруха от калькулятора, не взирая на роль, которую железка выполняет?

Я таки не понял, откуда взялись микрухи от калькулятора и в чём заключается твой вопрос?

Это вот эмбедед или нет? Если нет, то в чём ключевое отличие от этого твоего кубиборда?

Ну, наверное отсутствием GPIO? Вообще понятие эмбедед - достаточно расплывчатое. При некотором старании под него можно и Win2012Server притянуть.

Ну, наверное отсутствием GPIO?

Если я воткну туда микруху с парой пинов управляемых по усб, оно будет ембедед?

Если я воткну туда микруху с парой пинов управляемых по усб, оно будет ембедед?

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

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

Тоесть заявление «системд работает в ембедед» и «системд работает в летающем макаронном монстре» в принципе несут одинаковое количество полезной информации?

1) Wayland/Mir? 2) А запуск пульсы с приоритетом реального времени не спасает? 3) Проблема - факт. По идее systemd + cgroups должны решить. Может дистрибутивы ещё не подхватили достаточно свежие версии? 4) Дык RDP и использовать, не? Есть даже несколько независимых открытых реализаций, в том числе и бэкенд для Wayland. 5) А вот это не проблема, а вкусовщина - я даже из xfce себе сделал конфетку.

там, где udev тупо отказался собираться

Вот поэтому некоторые проекты и принципиально не принимают багрепорты с генту до тех пор пока проблему не воспроизведут на нормальном дистрибутиве. Вечно у их всё настолько через задницу, что даже udev собрать не могут.

Так нельзя же, разработчики пакетов впадают в истерию и пишут иниты для systemd?

Разработчики пишут так, как им удобно, не обращая внимания на идиотов, впавших в истерику по поводу systemd.

Есть девайсы на uClibc с udev

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

Ну, для мелкого embedded - системд жирноват.

Для мелкого embedded - GNU/Linux жирноват, а для обычного systemd подходит идеально ибо избавляет от кучи старых костылей: один баш для загрузки чего стоил.

Тоесть заявление «системд работает в ембедед» и «системд работает в летающем макаронном монстре» в принципе несут одинаковое количество полезной информации?

Потому-что ембедед мало чем отличается от летающего макаронного монстра. Проблема терминологии.

Системд работает под линуксами с glibc. Проверенно на процах adm64, x86, arm - это правильная формулировка.

В ембедед можно использовать adm64, x86, arm. Термин этого не запрещает. В ембедед может быть любое количество любой памяти. Термин это не оговаривает.

Так-что строго говоря, системд работает в ембедед системах, на которых можно установить линуксовое ядро и glibc.

Для мелкого embedded - GNU/Linux жирноват, а для обычного systemd подходит идеально ибо избавляет от кучи старых костылей: один баш для загрузки чего стоил.

Кстати да, если уж ядро впихнули, смысл экономить на спичках?

Так-что строго говоря, системд работает в ембедед системах, на которых можно установить линуксовое ядро и glibc.

Тоесть мы возвращаемся к тому, что заявлениям о системд в ембедед цена, как заявлениям о кроссплатформенности майкрософта?