Выпущен новый отчёт об успехах в разработке Debian GNU/Hurd

У меня несколько лет назад стоял, проблем особых не вспомню (только в процессе установки нужна была какая-то магия).

переход на систему инициализации SysVinit, которая заменила набор самописных shell-скриптов.

С тем же успехом можно было на systemd поехать. А столько криков было в темах про systemd о якобы кроссплатформенности sysvinit.

Сошлюсь на ман и анонимуса.

bit.trip.runner-1.0 просит нереального (комментарий)

Нет, это у кого-т плюсизм головного::мозга.

Меж тем, systemd прекрасно сочетается с хурдом

Не совсем, это PR-высер какой-то. Я переведу на простой язык.

Что sysvinit, что systemd придется или переписывать, или юзать костыли для Linux-совместимости (чтобы Hurd был похож на Linux и можно было ничего не переписывать). systemd местами интереснее и фичастее, но для него нужно сильно ядро допиливать... так что systemd пока откладывается, пилим sysvinit.

В Debian/FreeBSD делают также, чтобы использовать единую базу с Debian/Linux (проще наложить 1 патч на ядро, чем патчить кучу user-space утилит). А если посмотреть вглубь, то костыли отличаются - для sysvinit придется добавить файликов в /proc, или поменять их формат (для чего достаточно понимать что такое printf), а для systemd не хватает системных вызовов (что значительно сложнее и с точки зрения кодера и с точки зрения согласования API ОС).

мдя. но в gpl3 ж есть исключение для системных либ

С тем же успехом можно было на systemd поехать

Не с тем же.

Какая разница если и там и там надо городить костыли для linux-совместимости? Выбор sysvinit в данном случае вообще не понятен, его через пару лет закопают, как после этого они предполагают поддерживать базу пакетов от дебиана? Очередные костыли городить?

С тем же успехом можно было на systemd поехать

Не с тем же.

Какая разница

Разница между истинным и ложным утверждением? Ну я даже не знаю.

и там и там надо городить костыли для linux-совместимости

Только вот для совместимости systemd нужны на порядок большие усилия.

Выбор sysvinit в данном случае вообще не понятен

А он и не должен быть понятен _тебе_ - просто потому, что ты не в теме.

В свете санкций от RedHat http://safe.cnews.ru/top/2014/05/14/red_hat_blokiruet_rossiyskih_polzovateley...

Мысль не лишена смысла :)

Выбор sysvinit в данном случае вообще не понятен, его через пару лет закопают, как после этого они предполагают поддерживать базу пакетов от дебиана?

Systemd слишком прогрессивный для допотопного Hurd. Там всякие cgroups нужны, poll() и прочие навороты. А Hurd до такого уровня еще пилить и пилить.

Можно еще systemd пропатчить до поддержки hurd, но думаю поттеринг нахер пошлет с таким подходом - в апстриме systemd поддерживать hurd и ограничивать себя. Как-то так.

А RMS двадцать лет пилил, пилил, да так и не запилил

Да он языком чесал только...

poll() и прочие навороты

Жжош, эксперт.

http://www.youtube.com/watch?v=7t96m2ynKw0

Только свободные нарктики.

прикольно, празднуют полагаю:

25 июня 2009 – День памяти Любавичского ребе – главы современного поколения евреев.

poll() и прочие навороты

Жжош, эксперт.

ну да :) речь про epoll() конечно же. Он линукс-специфичный, API сложный. На уровне libc конечно может и получится его эмулировать, но все таки сложноват...

Мне помнится в *BSD тогда поднялся срач. Поттеринг не хотел уходить с epoll на POSIX-совместимые select/poll, а BSD не хотела стелится под systemd и усложнять API.

Ха-ха-ха. А колесо, это какой век?

Каменное? Как и Hurd?

А как во фре?

Во фре как и в гну хурд.

Поттеринг не хотел уходить с epoll на POSIX-совместимые select/poll

Как я его понимаю. Я бы тоже не захотел.

Поттеринг не хотел уходить с epoll на POSIX-совместимые select/poll, а BSD не хотела стелится под systemd и усложнять API.

как в итоге решили?

кто в результате из этих двоих — дал слабену? :-)

дал слабену?

Слабен - серб или болгарин?

API сложный

Если у епола апи сложный, то я испанский лётчик.

Так во фре же есть kqueue/kevent, бледным подобием которых является epoll. epoll достаточно прозаическая штука и где там сложный API совершенно непонятно.

Нет, это у кого-т плюсизм головного::мозга.

вы вообще об чём? о_О

Ха-ха-ха. А колесо, это какой век?

Каменное? Как и Hurd?

Ага. Мамонтом отложенное.

Ну теперь линуксу точно какец.

Теперь ни о чем — в тексте новости это уже исправили.

вы дурак?

вы вообще об чём? о_О

На будущее: если возжелаете сойти за адеквата, научитесь задавать вопросы как-то иначе... информационно-насыщеннее?

Основная проблема GNU/Hurd в том, что пилит его GNU. Это значит что ОС будет на столько свободна, что пользоваться её будет совершенно невозможно!

Свежие наработки в GNU Hurd: задействование DDE (Device Driver Environment), позволяющее использовать Linux-драйверы в Hurd, что разрешает проблемы с поддержкой оборудования; переход на pthreads; поддержка /proc/mtab;

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

кто в результате из этих двоих — дал слабену? :-)

Так вроде бы systemd официально и не работает в *BSD (хотя не знаю, может и есть порты прям systemd). У них там open launchd периодически всплывает (на основе исходников launchd от Apple). Пилят 1.5 энтузиаста.

Если мое имхо интересно - если делать по фен-шую, то Поттерингу надо написать кроссплатформенный код, не так сильно завязанный на особенности ОС. В POSIX-совместимых ОС это не суперсложно. Но Поттеренгу не надо BSD, так что он им не обязан ничего делать :)

Если у епола апи сложный, то я испанский лётчик.

epoll такой сложный, что только избранные его осиливают :) Проблема в том, что реализация epoll в BSD скорее всего будет посложнее, чем воткнуть лишний #define, или добавить отсутствующую strnlen. Ну и явно сложнее, чем освоить уже готовый printf (с которым и было сравнение).

Скажите, кто пробовал, оно юзабельно и непадуче или как?

мое имхо интересно - если делать по фен-шую, то Поттерингу надо написать кроссплатформенный код, не так сильно завязанный на особенности ОС

...так-то оно так .. но если в *BSD сделалют (или уже сделали?) epoll — то программисты скажут только спасибо :)

Новость интересная. Однако куда не беги, везде одни и те же DE. Один и тот же теаринг, кривой дизайн, отсутствие композитора, тормоза, кривые порты кривых программ.

haiku, aros/icaros, syllable

Во время работы проекта в рамках на Google Summer of Code был осуществлён переход на систему инициализации SysVinit

Деб, как всегда, идет в ногу со временем.

как программёры из АНБ подключились, так сразу дело пошло

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

что там с производительностью этого lor://forum/talks/9695738 ?

cat /proc/cpuinfo|sed -rn 's/.*el na.*: //p'|uniq -c; openssl speed md5 -multi `cat /proc/cpuinfo|grep 'el na'|wc -l` 2>&1|grep ^md5

я теперь понял, в чём была «шутка», но и вы, поверьте, адекватом не выглядели :)
на этом диалог можно завершить. спасибо!

но если в *BSD сделалют (или уже сделали?) epoll — то программисты скажут только спасибо :)

Это не часть POSIX. Так что все кто используют и хотят кроссплатфоменности - ССЗБ. Если бы разрабам BSD ткнули в несоответствие с каким-нибудь обновленным POSIX-2014, то сразу бы появилось...

POSIX, POSIX, ... блин, людям (программистам) работать нужно, а не молиться на этот ваш POSIX.

чем больше POSIX не удовлетворяет программистов — тем больше программисты перестают его любить.

ТОгда вопрос: КТо и зачем его придумал? ^_^

Слоупок-кун, речь про HURD, ты в курсе?

речь про HURD, ты в курсе?

В курсе. В то время как 5инит кругом закапывают в хурд добавили его поддержку. Весьма оперативно.

В дебе его тоже уже закапывают

Интересно, а Hurd from scratch никто написать не хочет?