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

"Релиз Debian 9.0 'Stretch' намечен на 17 июня"	+/–
Сообщение от opennews (??) on 27-Май-17, 09:09
Разработчики проекта Debian назначили (https://lists.debian.org/debian-devel-announce/2017/05/msg00...) дату релиза Debian 9.0 "Stretch". Релиз планируется выпустить 17 июня, в связи с чем запущена инициатива по проведению в этот день мероприятий (https://wiki.debian.org/ReleasePartyStretch), приуроченных к выходу Debian 9.0. В странах бывшего СССР мероприятий пока не назначено. В настоящее время насчитывается (http://bugs.debian.org/release-critical/) 120 критических для формирования релиза ошибок. До 6 июня планируется закрыть все эти ошибки. Проблемы которые не удастся устранить до этого дня будут помечены флагами  stretch-ignore или stretch-will-remove. За неделю до намеченного релиза (9 июня) все пакеты, помеченные флагом stretch-will-remove, будут удалены из репозитория, если в ветке Testing для них не будут предложены исправления критических проблем. Начиная с 9 июня ветка Testing будет полностью заморожена от внесения изменений (исключение делается только для экстренных вмешательств) URL: https://lists.debian.org/debian-devel-announce/2017/05/msg00... Новость: http://www.opennet.me/opennews/art.shtml?num=46606
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+/–
Сообщение от Аноним (??) on 27-Май-17, 09:09
Праздник！Вкатываю его сейчас на пролиант. Как раз к релизу заработает на боевом месте.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	8. "Релиз Debian 9.0 Stretch намечен на 17 июня"	–14 +/–
	Сообщение от Меломан1 on 27-Май-17, 10:11
	> Праздник！ Через 3 месяца релизнется CentOS 7.4 - будет настоящий праздник. Network Bound Disk Encryption, RAID Takeover и много-много обновлений и нового полезного функционала. В то время когда дебианщики готовы половину обновлений выкинуть лишь бы как-нибудь слатать релиз.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	10. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+8 +/–
	Сообщение от Аноним (??) on 27-Май-17, 10:35
	После выхода свежей версии CentOS тяну месяц-другой с обновлением,и всё равно непременно что-нибудь отваливается. Debian обновляю, не дожидаясь релиза, через некоторое время после заморозки, и как правило всё работает. Такая вот обратная (а кому и лицевая) сторона медали.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	79. "Релиз Debian 9.0 Stretch намечен на 17 июня"	–1 +/–
	Сообщение от _ (??) on 30-Май-17, 17:21
	Так было до 8-ки с систымдым. Это был первый за всю жизнь демьян который сам не перешел, ваааще анатендед, на новую версию. Пришлось засучить и белыми ручентками :-( Будем посмотреть что выйдет с 9-кой. Надеюсь вылижут как это было в преждние ...
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	82. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+/–
	Сообщение от Andrey Mitrofanov on 30-Май-17, 17:51
	> Так было до 8-ки с систымдым. Это был первый за всю жизнь > демьян который сам не перешел, ваааще анатендед, на новую версию. Никакого "анатендед" и "ваще сам" у них никогда не было. У вас - могабыть, а у них -- отдельная глава про Upgrading в ... то ли R.N., то ли в U.M., навскидку не помню сейчас. С пошаговыми "делай раз", "делай два" и приглащениями писать письма-баги, ежели что не так. И бэкапами -- обязательно в рекомендациях == "мы в домике". //Disclosure: Здесь wheezy 7.11 + LTS. Уверен, что в 8+ это не поменялось.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	80. "Релиз Debian 9.0 Stretch намечен на 17 июня"	–1 +/–
	Сообщение от _ (??) on 30-Май-17, 17:23
	>Через 3 месяца релизнется CentOS 7.4 ... и перечислил фичи ядра :-) Ну я возьму из бэк-портов такую же версию - и у меня все эти фишки будут :-р
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	19. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+/–
	Сообщение от Аноним (??) on 27-Май-17, 12:08
	> Вкатываю его сейчас на пролиант Удачи https://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug... > failed to boot in HP Proliant DL380 G5, but previous kernel does boot
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	52. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+/–
	Сообщение от Аноним (??) on 27-Май-17, 21:29
	>> Вкатываю его сейчас на пролиант > Удачи > https://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug... >> failed to boot in HP Proliant DL380 G5, but previous kernel does boot >   Всё как по маслу. У меня ген9 580.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	81. "Релиз Debian 9.0 Stretch намечен на 17 июня"	–1 +/–
	Сообщение от _ (??) on 30-Май-17, 17:27
	Не расстраивайся! Бедность - не порок! (С) Теллер в одном швейцарском банке :)
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

14. "Релиз Debian 9.0 Stretch намечен на 17 июня"	–4 +/–
Сообщение от бедный буратино (ok) on 27-Май-17, 11:09
на моём основном компьютере - ниработаит. так что или обновлю всё, кроме ядра (останусь на 3.16), или буду искать другое ядро. сначала не работало, пока не заблеклистишь звук, а теперь не работает видео, если не уберёшь kms, и тогда можно только сидеть в консоли 80x25
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	15. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+1 +/–
	Сообщение от Аноним (??) on 27-Май-17, 11:34
	Основной - Пентиум? Может пришло время что то менять?
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	20. "Релиз Debian 9.0 Stretch намечен на 17 июня"	–3 +/–
	Сообщение от бедный буратино (ok) on 27-Май-17, 12:09
	такой, какой мне более удобен, тот и основной работает, меня устраивает. а вот новое ядро почему-то не устраивает. значит, основной ОС там будет не Debian, а OpenBSD. а Debian 8, который будет ещё поддерживаться в рамках LTS, будет на случай, когда понадобится kvm/virtualbox или флеш-видео
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	47. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+/–
	Сообщение от Аноним (??) on 27-Май-17, 20:26
	man reportbug
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	75. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+/–
	Сообщение от ryoken (ok) on 29-Май-17, 07:44
	> на моём основном компьютере - ниработаит. так что или обновлю всё, кроме > ядра (останусь на 3.16), или буду искать другое ядро. (aptosid или liquorix в помощь)
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

16. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+/–
Сообщение от Аноним (??) on 27-Май-17, 11:49
Пока не понял в чём проблема, но в новой версии systemd перестало работать оповещение о старте процесса через systemd-notify --ready (ну и пробовал READY=1 через socat в bash, и вариант через python). У процесса Type=notify, NotifyAccess=all. Переменную окружения с путём к сокету проверял, передаёся. Но из дочернего процесса сообщение через сокет не приходит, похоже. При этом в списке дочерних процессов по команде статуса дочерний процесс значится. Сервис завершается по таймауту. При этом сама команда systemd-notify --ready успешно завершается, что очень удивляет. Но если запустить службу заново, то всё работает. В прошлой версии Debian не работало в случае, если дочерний процесс был запущен из-под другого пользователя. Видимо придётся отлаживать systemd, правда пока даже с чего начать не знаю.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	26. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+7 +/–
	Сообщение от danonimous on 27-Май-17, 14:06
	Переходи на Devuan - там нет этих проблем.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	33. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+/–
	Сообщение от Аноним (??) on 27-Май-17, 16:09
	Вообще, достаточно бессмысленные советы. Чтобы реализовать то же самое на скриптах bash мне понадобилось бы гораздо больше времени и строчек кода. Как минимум мне самому пришлось бы реализовывать межпроцессное взаимодействие для распараллеленной загрузки моих служб по событийной модели. Мне и так хватает этого в коде на Си. И если с парой-тройках служб это ещё можно сделать без автоматизации, то с 10-ю мне пришлось бы уже сильно поднапрячься и реализовывать свою систему загрузки с зависимостями. Ну и зачем мне это, если такую систему уже изобрели до меня? Меньше времени уж тогда займёт, разобраться с исходниками, сделать и отправить патч, если там есть ошибка. Я понимаю, что это деление на за и против - вроде субкультур, но тут дела программистов. Если для обычного человека при переходе на двухядерный процессор с меньшей частотой всё просто стало работать медленнее, то программист знает, что на тот момент разработчики ПО просто не заморачивались на многопоточность. Это просто аналогия, но, думаю, вы поняли идею.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	42. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+2 +/–
	Сообщение от freehck (ok) on 27-Май-17, 17:42
	> Чтобы реализовать то же самое на скриптах bash мне понадобилось бы гораздо больше времени и строчек кода. > (ну и пробовал READY=1 через socat в bash, и вариант через python). socat-то конечно "проще", чем netstat -nxp | grep ... > И если с парой-тройках служб это ещё > можно сделать без автоматизации, то с 10-ю мне пришлось бы уже > сильно поднапрячься и реализовывать свою систему загрузки с зависимостями. LSB-заголовки в run-скриптах init.d обеспечивают загрузку по зависимостям.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	44. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+/–
	Сообщение от Аноним (??) on 27-Май-17, 19:03
	Система зависимостей предполагает оповещение о том, что процесс проинициализировался (например, сервер проинициализировал сокет к нему можно подключаться), а не просто запустился. Не успел столкнуться в с этим в SysV, но может расскажете, как там процесс оповещает о том, что он готов? У systemd описание unit-файлов в этом плане достаточно простым и понятным оказалось. Есть, конечно много спорных моментов, но в целом пригодно к использованию.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	49. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+2 +/–
	Сообщение от Аноним (??) on 27-Май-17, 20:36
	> Система зависимостей предполагает оповещение о том, что процесс проинициализировался > (например, сервер проинициализировал сокет к нему можно подключаться), а не просто > запустился. Не успел столкнуться в с этим в SysV, но может > расскажете, как там процесс оповещает о том, что он готов? У > systemd описание unit-файлов в этом плане достаточно простым и понятным оказалось. > Есть, конечно много спорных моментов, но в целом пригодно к использованию. Если есть зависимость от сокета, решается вбиванием перед запуском костыля типа while ! [ -S "$SOCKET" ]; do sleep 1; done Но на самом деле ситуация довольно редкая. Большинство демонов пытаются подключиться к сокету не сразу при запуске, а только когда возникает необходимость, и если им это не удалось — спокойно переподключаются позднее. Если там наколенная поделка — лучше её допилить, чтобы она вела себя именно так, даже при использовании systemd.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	53. "Релиз Debian 9.0 Stretch намечен на 17 июня"	–3 +/–
	Сообщение от Аноним (??) on 27-Май-17, 22:16
	Большая часть межпроцессного взаимодействия в Линуксе построена на сокетах (unix-). Если есть зависимость, значит она вероятнее всего будет связана с запуском сервера. Костыли со sleep - это бред. Допускаются только блокирующиеся операции. Полагаю, что большая часть ПО в дистрибутиве будет использовать сокеты. Самый простой пример - Иксы. Другой пример - d-bus. И как думаете, что будет, если сначала стартануть Иксы, а затем openbox? openbox попытается подключиться к иксам, которые ещё не успели начать прослушивать unix-сокет. Конечно, в дистрибутивах так не делают (openbox скорее всего будет просто дочерним процессом для иксов), это вполне допустимая ситуация.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	55. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+2 +/–
	Сообщение от Аноним (??) on 27-Май-17, 23:04
	И как же, по-Вашему, все жили без systemd? Недоступность сокета — это рядовая ситуация, а не фатальная ошибка, особенно если учесть, что сокет может быть не только локальным, но и сетевым. Все демоны (именно демоны, запускаемых руками клиентских приложений это не касается) должны уметь обрабатывать такую ситуацию.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	59. "Релиз Debian 9.0 Stretch намечен на 17 июня"	–1 +/–
	Сообщение от Аноним (??) on 28-Май-17, 08:42
	Может приведёте хотя бы один пример? Я по опыту не помню подобных ситуаций. Обычно  просто делается завершение работы и всё.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	60. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+/–
	Сообщение от Аноним (??) on 28-Май-17, 12:03
	Приведите пример того, что завершается.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	62. "Релиз Debian 9.0 Stretch намечен на 17 июня"	–2 +/–
	Сообщение от Аноним (??) on 28-Май-17, 15:16
	openbox, x11vnc, zenity и скорее всего любое графическое приложение, если сокет иксов не создан. Это из того, с чем сталкивался на своём опыте. Другой пример, посерьёзнее. Что будет, если прокси-сервер nginx стартанёт после сервера bind9, в котором локальная доменная зона, указанная в конфигурации nginx? Ну и попробуйте запустить какой-нибудь сервис, работающий через dbus, а только потом запустите сам dbus. Тут проверять необходимо, т.к. можно было реализовать через inotify с мониторингом каталога, в котором сокет должен находиться. Но это не портабельно.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	64. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+/–
	Сообщение от Аноним (??) on 28-Май-17, 18:36
	> openbox, x11vnc, zenity и скорее всего любое графическое приложение, если сокет иксов не создан А что системде уже и их сам запускает? Вообще это совершенно не дело системы инициализации. Я, повторюсь, писал про >> именно демоны, запускаемых руками клиентских приложений это не касается > Что будет, если прокси-сервер nginx стартанёт после сервера bind9, в котором локальная доменная зона, указанная в конфигурации nginx? Думаю, выдаст на пришедший в этот момент запрос 502, после поднятия бинда заработает нормально. Разве не так? > попробуйте запустить какой-нибудь сервис, работающий через dbus, а только потом запустите сам dbus Много ли системных сервисов используют dbus, кроме системде? Я ни одного не припоминаю, так что сделать этого, увы, не смогу.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	65. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+/–
	Сообщение от Аноним (??) on 28-Май-17, 21:09
	> Думаю, выдаст на пришедший в этот момент запрос 502, после поднятия бинда заработает нормально. Разве не так? Ну, вы так думаете из-за того, что не знаете, как работает ДНС и как делается обработка ошибок в ПО (lazy). nginx в Debian 7 делает запрос ip-адреса, чтобы начать прослушивание. Но т.к. адреса нет просто завершается по ошибке. И сюрприз, сайт лежит. Но достаточно его стартануть опять, как он снова работает. И не каждый сисадмин догадается в чём дело. А проблема проявлялась, когда сервер DNS включали после того, как включали сервер, на котором nginx был в роли прокси-сервера. Обычное состояние гонки. Даже не обязательно, чтобы это были зависимости процессов, проблема может быть даже на разных компьютерах. Но да, есть ПО, которое корректно обрабатывает такие ситуации. Например, openvpn. > Много ли системных сервисов используют dbus, кроме системде? Я ни одного не припоминаю, так что сделать этого, увы, не смогу. Хм. Убейте демон dbus и попробуйте сделать что-нибудь через NetworkManager. ;)
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	61. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+/–
	Сообщение от Аноним (??) on 28-Май-17, 12:06
	Просто вот даже растерялся как-то, всё тупо работает, и никогда не задумывался, что там с сокетами на момент запуска... Ну скажем nginx и не подумает завершаться, если не достучится до сокета какого-нибудь php-fpm.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	54. "Релиз Debian 9.0 Stretch намечен на 17 июня"	–2 +/–
	Сообщение от Аноним (??) on 27-Май-17, 22:23
	>> Чтобы реализовать то же самое на скриптах bash мне понадобилось бы гораздо больше времени и строчек кода. >> (ну и пробовал READY=1 через socat в bash, и вариант через python). > socat-то конечно "проще", чем netstat -nxp | grep ... Сначала не обратил внимания, причём тут netstat вообще? Название сокета в переменной окружения есть. Права доступа я могу через консоль посмотреть.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	76. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+/–
	Сообщение от freehck (ok) on 29-Май-17, 16:29
	>>> Чтобы реализовать то же самое на скриптах bash мне понадобилось бы гораздо больше времени и строчек кода. >>> (ну и пробовал READY=1 через socat в bash, и вариант через python). >> socat-то конечно "проще", чем netstat -nxp | grep ... > Сначала не обратил внимания, причём тут netstat вообще? > Название сокета в переменной окружения есть. > Права доступа я могу через консоль посмотреть. Соображений тут много. Начнём с того, что файл unix-сокета может уже быть, но его не обязательно слушают. Проверяется легко: между bind() и listen() вставьте usleep в тысячу секунд. (Это я пишу для комментаторов выше, которые рекомендуют [ -S "$socket" ] в цикле). Я берусь утверждать, что socat использовать для проверки сокета хуже по причине того, что он в обязательном порядке пытается что-либо послать, то есть непосредственно устанавливает соединение. В то же время netstat проверяет состояние сокета без установки соединения. Вот Вы посылаете, как я понял, строку "READY=1" через socat. Откуда нам знать, что демон на той стороне корректно реагирует на это сообщение? Если уж использовать socat, то я бы воздержался от посылки чего бы там ни было, ограничившись чем-то вроде echo -n | socat - UNIX-CLIENT:/tmp/checker.socket Это безопаснее, хотя и не лишено недостатков: что, если демон при отсутствии ввода после установки соединения зависает? Мне вот когда-то такой демон попадался. Давно, правда, дело было, я уже не вспомню название. Но такое бывает. Посему во избежание проблем всё-таки правильнее имхо использовать netstat, грепая по имени сокета и слову LISTEN. Этот вариант безопасен и не вызывает проблем от слова совсем: грепнуть вывод netstat гораздо проще, чем разгребать возможные проблемы, связанные с использованием socat.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	77. "Релиз Debian 9.0 Stretch намечен на 17 июня"	–1 +/–
	Сообщение от Аноним (??) on 29-Май-17, 19:42
	socat был необходим лишь для эксперимента, чтобы убедиться, что данные в сокет вообще уходят. То, что они приходят к демону понятно и так, т.к. не было возвращено ошибок. Соответственно на стороне сервера была исполнена read(). Вообщем, обходной путь найден, но в systemd ошибка присутствует. systemd-notify абсолютно неработоспособна. Пока могу предполагать, что проблема из-за того, что systemd пытается определить принадлежность к cgroups по PID. Но делает это после того, как сообщение было получено. Соответственно, процесс уже завершился, а сообщение игнорируется, т.к. невозможно было определить cgroup. Идея интересная, - один сокет на все процессы, но реализация, похоже, неграмотная. Я бы в протокол добавил обязательно ожидание подтверждения от демона того, что сообщение получено. Блокирующийся read() не дал бы процессу завершиться и можно было бы определить его cgroup. Но как именно там реализовано пока не знаю. Обходной путь - переписать скрипт c bash на python и использовать systemd.daemon.notify('READY=1'). Пока устраивает. Отчёт об ошибке отправлен в Debian. Сам я пытался найти место, где происходит приём сообщений, но пока не нашёл. Код там нельзя назвать интуитивно понятным. Нашёл функцию, которая определяет cgroup по PID, но по её вызовам не нашёл абсолютно ничего полезного. Даже по слову READY я не смог найти место, где данная строка обрабатывается.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	78. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+/–
	Сообщение от Аноним (??) on 29-Май-17, 19:55
	Учитывая, что тут любят придираться к мелочам, поправлю себя и уточню: read(), либо же recv().
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

17. "Релиз Debian 9.0 Stretch намечен на 17 июня"	–1 +/–
Сообщение от Аноним (??) on 27-Май-17, 11:51
автомонтирование флешек работает? В jessie сломали.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	18. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+/–
	Сообщение от Аноним (??) on 27-Май-17, 12:03
	Не подтверждаю. Jessie, KDE, systemd, все работает.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	21. "Релиз Debian 9.0 Stretch намечен на 17 июня"	–2 +/–
	Сообщение от бедный буратино (ok) on 27-Май-17, 12:10
	> автомонтирование флешек работает? В jessie сломали. зато wget починили - а то у них была фирменная фишка в чётных версиях ломать wget - так было и в squeeze и в jessie
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	31. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+/–
	Сообщение от Аноним (??) on 27-Май-17, 15:54
	а прогрессбар при скачивание в несколько строчек?
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	39. "Релиз Debian 9.0 Stretch намечен на 17 июня"	–2 +/–
	Сообщение от бедный буратино (ok) on 27-Май-17, 16:41
	> а прогрессбар при скачивание в несколько строчек? в том-то и дело, что починили :)
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	50. "Релиз Debian 9.0 Stretch намечен на 17 июня"	–2 +/–
	Сообщение от Аноним (??) on 27-Май-17, 20:39
	> автомонтирование флешек работает? В jessie сломали. Не то чтобы совсем сломали, но без systemd не работало. Полагаю, что не работает по-прежнему. Починить можно только пересборкой policykit без systemd или переходом на devuan.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

22. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+2 +/–
Сообщение от Аноним (??) on 27-Май-17, 13:18
Есть ли смысл переходить с Devuan? Есть ли значительные преимущества?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	23. "Релиз Debian 9.0 Stretch намечен на 17 июня"	–7 +/–
	Сообщение от Отражение луны (ok) on 27-Май-17, 13:25
	- 10 к интеллекту + 25% лайков на опеннете Активная способность: рассказать всем как сильно ты ненавидишь systemd. Возможно использовать когда всем окружающим на$рать.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	27. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+4 +/–
	Сообщение от Аноним (??) on 27-Май-17, 14:29
	>> смысл переходить с Devuan? > - 10 к интеллекту Т.е. использование системДы делает глупее. Что-то такое я подозревал. > + 25% лайков на опеннете Засилье фанатов Лёни на опеннете трудно отрицать. > Активная способность: рассказать всем как сильно ты ненавидишь systemd. Т.е. у системдышнеков наклонности мазохистов или же просто некоторые психологические отклонения, типа раздвоения личности? Спасибо за откровения, буду и далее держаться от них подальше!
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	30. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+1 +/–
	Сообщение от username (??) on 27-Май-17, 15:01
	Интересно чтобы он сказал про переход на runit. Наверное минус 90 к интеллекту.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	45. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+1 +/–
	Сообщение от Аноним (??) on 27-Май-17, 20:12
	*что бы
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	36. "Релиз Debian 9.0 Stretch намечен на 17 июня"	–2 +/–
	Сообщение от Отражение луны (ok) on 27-Май-17, 16:30
	Ты не уловил суть) Системд хейтеры играются со своими девуанами, а затем переходят на настоящие дистрибутивы, засирая при этом все новости постами о том, как они этим недовольны)
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	25. "Релиз Debian 9.0 Stretch намечен на 17 июня"	–6 +/–
	Сообщение от Аноним (??) on 27-Май-17, 14:00
	Если Вас не волнует скорость загрузки системы, не интересуют новые версии ПО, и Вы не занимаетесь администрированием, - то нет, никакого смысла  переходить нет.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	28. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+11 +/–
	Сообщение от Аноним (??) on 27-Май-17, 14:48
	> Если Вас не волнует скорость загрузки системы, Это вот так, да? https://www.youtube.com/watch?v=hx30Z7_G-vk > archbang - systemd vs openRC (speed load sytem) да не расстраивайтесь вы, ваш любимый системд только немного медленне ... хотя да, он же вроде вначале пропихивался именно под таким соусом - обеспечить быструю загрузку. Получается, Рыжий в Красной Шляпочке вас немножечко на***л, да? =) > не интересуют новые версии ПО, Про новые версии ПО - это конечно мечта всех Истинно Верующих Последователей Рыжего, но пока что еще далеко не всем сумели запихнуть свою привязку, хотя стараются, да: https://github.com/tmux/tmux/issues/428 > With systemd 230 we switched to a default in which user processes started as part of a > login session are terminated when the session exists (KillUserProcesses=yes). > [] > Unfortunately this means starting tmux in the usual way is not effective, because it will > be killed upon logout. There are a few option to avoid that, the best being: > systemd-run --scope --user tmux > This starts tmux as a scope unit under the systemd --user instance. > It would be great if tmux could do this automatically. Probably the best way to do this would be to make the > dbus call to org.freedesktop.systemd1.Manager.StartTransientUnit directly from tmux. See скромно, ага. «мы тут подумали и Леннарт Неповторимый решил, что пора немного cломать поведение демонов, немогли бы вы вставить костыль в свою программу, чтобы мы могли и далее делать вид, что все в порядке?» А вот что ответил автор тмукса: > My concern is that we have a little function, daemon(), that does a simple little procedure to make > a daemon that has worked basically unchanged across multiple platforms for maybe, what, 30 years? > Now to do the same thing we need to add 150 lines of new, Linux-only code AND a library dependency. Ответил без должного почтения, да еще и отказом. Нехорошо то как!
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	35. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+/–
	Сообщение от Аноним (??) on 27-Май-17, 16:20
	> speaking as the Debian maintainer I'm okay with adding a dependency on libsystemd to the package очешуеть
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	43. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+2 +/–
	Сообщение от Аноним (??) on 27-Май-17, 18:05
	>> speaking as the Debian maintainer I'm okay with adding a dependency on libsystemd to the package > очешуеть Это проблемы мейнтейнера. Однако от автора требуют встроить поддержку дбаса. Причем, в лучших традициях этой наглой братии - не присылая хотя бы полусырой патч, нет: > It would be great if tmux could do this automatically. > Probably the best way to do this would be to make the dbus call to > org.freedesktop.systemd1.Manager.StartTransientUnit directly from tmux. See > https://github.com/systemd/systemd/blob/master/src/run/run.c... for how systemd-run > does it, and https://www.freedesktop.org/wiki/Software/systemd/dbus/ for the description of the API. т.е. вот так мы делаем в системде, вот АПИ, вперед и с песней.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	63. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+/–
	Сообщение от eleksir on 28-Май-17, 16:44
	Ну, да, теперь они прут внаглую: мы апстрим и будь нам благодарен, что тебя с твоим г. не только заметили, но и указали на _твою_ недоработку (несовместимость с нашим божественным сисд!) и, да, наши гайдлайны (читай "скрижали") включают в себя обязательную несовместимость с остальными ОС, и ежеполугодичные ломания API, чтобы разработчикам не было скучно. Так что взял свой код и БЫСТРО ИСПРАВИЛ, ЯСНО?!! это _приказ_! Примерно так. Уважение? нет! скажите "спасибо", что вас матами не обложили. А что касается dbus и зависимости на libsystemd так это... извиняйте, _дань прогрессу_ Вполне себе нормальный подход фанбоев от разработчиков сисд. Это не значит, что этих фанбоев не надо ногами по морде бить за умышленный саботаж на уровне экосистмы OpenSource. Но для этих убл*дков есть свой котёл по ту сторону добра и зла...
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

34. "Релиз Debian 9.0 Stretch намечен на 17 июня"	–1 +/–
Сообщение от Аноним (??) on 27-Май-17, 16:14
> в связи с чем запущена инициатива по проведению в этот день мероприятий, приуроченных к выходу Debian 9.0. Столы накрывать будут?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	48. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+1 +/–
	Сообщение от Аноним (??) on 27-Май-17, 20:32
	Ubuntu уже свой "фирменный" накрыла.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

40. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+/–
Сообщение от Аноним (??) on 27-Май-17, 16:47
Поздно, Devuan уже вышел.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

41. "Релиз Debian 9.0 Stretch намечен на 17 июня"	–2 +/–
Сообщение от Аноним (??) on 27-Май-17, 17:32
У меня опять шаблон рвётся: - будет готово как только будет готово - всё что не будет готово к 9 июня будет удалено Одно из этих утверждений насквозь лживо.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	46. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+/–
	Сообщение от Аноним (??) on 27-Май-17, 20:20
	Вот оно и будет готово, как только всё что не готово, будет удалено.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

51. "Релиз Debian 9.0 Stretch намечен на 17 июня"	–2 +/–
Сообщение от efimius (ok) on 27-Май-17, 20:46
Стоит сейчас на ноут вместо убунты ставить? Или лучше арч? Все равно собираюсь на ssd пережать
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	58. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+/–
	Сообщение от Аноним (??) on 28-Май-17, 08:37
	Сиди на 14й убунте и разбирайся с гентой.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	85. "Релиз Debian 9.0 Stretch намечен на 17 июня"	–1 +/–
	Сообщение от efim on 01-Июн-17, 01:57
	была 16ю04 теперь арч
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	71. "Релиз Debian 9.0 Stretch намечен на 17 июня"	+/–
	Сообщение от Аноним (??) on 28-Май-17, 23:05
	> Все равно собираюсь на ssd пережать Лучше используй "не ssd, а что-то человеческое"(с) опнет.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

83. "Релиз Debian 9.0 Stretch намечен на 17 июня"	–1 +/–
Сообщение от Аноним (??) on 30-Май-17, 20:24
systemd когда выпилят тогда и праздновать будем!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

84. "Релиз Debian 9.0 Stretch намечен на 17 июня"	–1 +/–
Сообщение от efim on 01-Июн-17, 01:55
поздно на arch уже
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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