при следующей загрузке могут быть выданы уже совсем другие имена

Баба-яга Freedesktop против:

With this new scheme you now get:
* Stable interface names across reboots

Зря придумывали, что ли?

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

Чувак, ты ходячий фейспалм.

Полный плаг-н-плей, разве что фанатам сусьтемд придётся писать после подключения что-то типа dhclient enp0s13u6u6c6i2 (нет, они правда это в своих udev-правилах генерируют.)

Т.е. сначала ты гонишь на Predictable Network Interface Names. Потом я тебе долго и упорно пытаюсь вдолбить, что раньше была куча проблем, но пришёл Predictable Network Interface Names и решил всё это.

Как всё сложно. А ведь был раньше одинокий /lib/udev/rules.d/75-persistent-net-generator.rules, который легко переопределялся в пару строк новым файлом в /etc/udev/rules.d.

Ты говоришь, что Predictable Network Interface Names — фигня и клёво было раньше.

Freedesktop против:

А потом мне же рассказываешь про Predictable Network Interface Names?!

разные кучерявые смены MAC

Рандомно генерируемый MAC-адрес — вполне жизненная ситуация. Read-only файловая система — тоже жизненная ситуация.

очень легко и просто может поменяться его путь

А вот каким образом сетевая карта от загрузки к загрузке будет скакать из одного PCI-порта в другой, мне непонятно.

Ну ок, если это телефон и usbnet, то название интерфейса будет зависеть от USB-порта, в который мы вставили телефон. Но если нам нужно задать для этого подключения недефолтные настройки, то для systemd-networkd это не проблема: там можно выбирать устройства не только по persistent path, но и по MAC-адресу. Для NetworkManager тоже.

А ещё более красивое решение: настроить systemd так, чтобы для usb-сетевых карт имя интерфейса задавалось не на основе порта, а на основе MAC-адреса (такая возможность есть).

я тебе долго и упорно пытаюсь вдолбить, что раньше была куча проблем, но пришёл Predictable Network Interface Names и решил всё это.

при следующей загрузке могут быть выданы уже совсем другие имена

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

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

при следующей загрузке могут быть выданы уже совсем другие имена

Если они при следующей загрузке совершенно другие, то какие они, нафиг, predictable?

Правильно, это я рассказывал про то, что было до введения predictable.

Ты сам себе уже противоречишь, вот я к чему.

Вообще-то, это ты.

А ещё вероятней, что ты банально путаешь predictable и persistent.

Нет.

А если первое без второго всё равно не работает

Работает.

Хорош флеймить тут, ты успел запутаться ещё двумя постами выше.

Не нужно.

Ради этого явно стоило стать модератором.

Зато у нас с тобой отныне общий ТВИМ на двоих.

Зато у нас с тобой отныне общий ТВИМ на двоих.

Только смысловая нагрузка у него разная.

кайфует от божественного oneplusone

Fixed.

Зато у нас с тобой отныне общий ТВИМ на двоих.

Сделай полезное дело, пофикси заголовок.

-Вышла новая версия библиотеки для работы с устройствами фирмы Apple — libimobiledevice 2.0
+Вышла новая версия библиотеки для работы с устройствами фирмы Apple — libimobiledevice 1.2.0

Сам ты запутался: из сообщения в сообщение распинаешься про прелести persistent-net, которому дела нет до того, какие мы имена интерфейсов генерируем (он спокойно может сохранять (и сохранял) старомодные eth123), а потом ты внезапно делаешь вывод, что

пришёл Predictable Network Interface Names и решил всё это

Другими словами, из

Если мы не можем сохранить в 70-persistent-net.rules, какие имена интерфейсам сейчас выдали, то при следующей загрузке могут быть выданы уже совсем другие имена

следует, что смешные именования вида enp13u666 не обладают теми волшебными свойствами, которыми наделяют их чуваки с freedesktop. Ну и нафиг они тогда нужны? Если же это неправда, и генерируются имена всё-таки предсказуемо, то зачем нам тогда вообще упарываться по сохранению 70-persistent-net.rules? Ведь при следующей загрузке имена интерфейсов остаются ровно теми же!

Не обольщайся.

Прочитай ещё раз своё исходное сообщение:

thriller

разве что фанатам сусьтемд придётся писать после подключения что-то типа dhclient enp0s13u6u6c6i2 (нет, они правда это в своих udev-правилах генерируют.)

enp0s13u6u6c6i2 — это predictable name. В твоём сообщении читается его явное недолюбливание. ОК, запомнили.

Также в этом сообщении есть явная неточность: «это» «они» генерируют вовсе не в udev-правилах, этим занимается net_setup_link udev builtin. Об этом я написал в своём первом ответе:

gentoo_root

thriller

нет, они правда это в своих udev-правилах генерируют.

Это неправда, правила udev вообще ни при чём. Дефолтная NamePolicy указывается в /usr/lib/systemd/network/99-default.link, её легко можно изменить, если создать файл /etc/systemd/network/99-default.link, там можно и вернуть унылый старый порядок именования (однако персистентность названий интерфейсов не гарантируется) и попробовать другие варианты. Парсится потом это udev'ом:

systemd.link(5)

Network link configuration is performed by the net_setup_link udev builtin.

Ты же начал гнать:

thriller

Как всё сложно. А ведь был раньше одинокий /lib/udev/rules.d/75-persistent-net-generator.rules, который легко переопределялся в пару строк новым файлом в /etc/udev/rules.d.

Вооооот, ты фанат /lib/udev/rules.d/75-persistent-net-generator.rules! А этот файлик — это persistent names. Вспоминая твоё недолюбливание predictable names, я делаю вывод, что ты любишь persistent names.

После этого я рассказываю, почему persistent names — какашка, ты несколько раз показываешь свою некомпетентность в вопросе. И на очередное объяснение, почему persistent names не работают, ты отвечаешь ссылкой на описание predictable names. Но ведь стоп! Я же до этого только тем и занимался, что агитировал против pertistent names и за predictable names, а ты пытался некомпетентно возражать и в итоге сам же кидаешь мне ссылку на predictable names! Я могу расценивать это как неудачную попытку троллинга. Итак, мы выяснили, что ты просто тролль.

Теперь насчёт последнего сообщения.

Если же это неправда, и генерируются имена всё-таки предсказуемо, то зачем нам тогда вообще упарываться по сохранению 70-persistent-net.rules?

70-persistent-net.rules не создаётся при использовании predictable names. Там даже создавать его некому. Он использовался раньше, до появления predictable names.

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

«это» «они» генерируют вовсе не в udev-правилах, этим занимается net_setup_link udev builtin

Не самая страшная неточность: присвоением имён всё равно занимаются (занимались?) в udev-правилах, даже если мы вынесем их генерацию в совершенно независимый скрипт.

Вооооот, ты фанат /lib/udev/rules.d/75-persistent-net-generator.rules

Вообще тут я даже не про persistent v predictable отвечал, а выражал недовольство тем, что конфигурирование механизма обеспечения консистентности наименований интерфейсов теперь размазали ещё сильней без особого на то профита.

Anyway, я понял, где я неправ: я почему-то упорно помнил, что 75-persistent-net-generator.rules занимается и persistent, и присвоением predictable, а мой /etc/udev/rules.d/75-persistent-net-generator.rules успешно отключал обоих (надо ли говорить, что это работало, хоть и по-другому?). Чего уж там, при его наличии я даже и не заметил, что persistent уже давно успели убрать из udev. Отсюда и вытекают оригинальный комментарий про /lib/udev/rules.d/75-persistent-net-generator.rules (для густых и шелковистых имён хватало именно его переопределения) и коммент про NAME="$env{INTERFACE_NEW}".

В Юнити(nautilus) все ок, да. А вот kde-dolphin работал не всегда корректно

В Юнити(nautilus) все ок.

Ничего там не ОК, а этак удовлетворительно, причём только с ubuntu 14.04 этим стало можно пользоваться.

Это не правда. У меня вообще нет /usr/lib/systemd/network/99-default.link т.к. нету системд за не надобностью, и такие дебильные имена интерфейсам задает именно udev.

Это не правда.

Выходит, маны врут?

У меня вообще нет /usr/lib/systemd/network/99-default.link

Возможно, есть другой /usr/lib/systemd/network/*.link или /etc/systemd/network/*.link, или же он лежит по какому-то другому пути. Возможно, никакого нет, и у udev есть какой-то дефолт на этот случай. Если это какой-то форк udev'а, наверняка там поменяли путь или вообще убрали этот конфиг и сделали захардкоженный дефолт.

такие дебильные имена интерфейсам задает именно udev.

А я именно это и сказал:

gentoo_root

Парсится потом это udev'ом:

systemd.link(5)

Network link configuration is performed by the net_setup_link udev builtin.

Это обычный udev из генту (не eudev). Система просто собрана с -systemd

кайфует от божественного oneplusone

Fixed.

Всё правильно пофиксил. Два чая этому господину.

Ну, да. Это ведь их конек.

Решается это использованием стороннего медиаплеера на огрызкофоне, не использующего медиатеку iTunes, а играющего файлы из своей песочницы. Тогда все просто, подключаем через libimobiledevice как флешку, закидфываем файлы в плеер, слушаем, профит ...

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

доступ к Containers\Shared\AppGroup

всем привет!

Кто-нибудь может подсказать, можно ли с помощью новой либы 1.2.0 получить доступ к Containers\Shared\AppGroup\{app id} папке? Эта фича пояилась в 8x.

С помощью house_arrest есть доступ только к к Containers\Data\Application\{app id}.

{app id} уже известно для Containers\Shared\AppGroup папки.

Прошу помощи. Может каким-то другим способом.

Был 75-persistent-net-generator.rules. Стал 99-default.link. У вас синдром утёнка или где?

Был 75-persistent-net-generator.rules. Стал 99-default.link. У вас синдром утёнка или где?

Может, человек не любит бессмысленные переименования туда-сюда?

Судя по его высказыванию, человек не любит, когда «всё сложно». Я лишь опроверг это суждение — стало не сложнее, а во многом даже понятнее (поскольку kind of DSL).

В контексте замены пустым файлом уж точно не сложнее.

вы о чем?

Что значит «о чём»? Я ответил на комментарий (другого человека).

:D сорри, чет я натупил. последняя активность в ветке была 17.02.2015, я подумал, что вы мне пишите )

А, это ещё и некроветка. Я в трекере увидел и пошёл читать с конца, на даты не обращая внимания.

Да, лучше создай новую тему в Development. Здесь хрен кто заметит.