Arch Linux перешел на использование системной директории /run
2Иллюстрация с сайта archlinux.org
Разработчики дистрибутива Arch Linux сообщили о переходе с системных директорий /var/run и /var/lock на /run и /run/lock соответственно. Изменение вступает в силу с выходом пакета filesystem-2012.6-2.
На данный момент старые директории (/var/run, /var/lock) остаются в системе, превращаясь в символьные ссылки на их новые места в /run. Тенденция перехода Linux-дистрибутивов на использование /run началась весной прошлого года, когда Леннарт Поттеринг (Lennart Poettering) объявил о появлении /run в Fedora, openSUSE, Ubuntu и Debian. Разработка Леннарта — init-система systemd — уже активно использует это нововведение (/run) в своей работе.
Вот и Arch Linux последовал примеру популярнейших Linux-дистрибутивов, перейдя на использование /run. Разработчики предупреждают, что во многих инсталляциях Arch Linux уже использовались каталоги /run, однако их наличие не было зафиксировано в каком-либо пакете дистрибутива. Теперь же /run официально закреплен посредством системного пакета «filesystem».
Постоянная ссылка к новости: http://www.nixp.ru/news/11799.html. Дмитрий Шурупов по материалам archlinux.org.
- В ведущих Linux-дистрибутивах появится каталог /run 7 6 31 марта 2011 г.
- Обзор обновлений в systemd: привязка к /run, интеграция с journald, переход на LGPL… 2 23 апреля 2012 г.
- Arch Linux меняет XFree86 на XOrg (в Current) 13 июля 2004 г.
- Arch Linux перешел на сжатие xz для своих пакетов 2 24 марта 2010 г.
- Дистрибутив Arch Linux начинает переход на systemd 2 7 17 августа 2012 г.
- Arch Linux больше не поддерживает Arch Build System 1 16 мая 2017 г.
- Arch Linux прекратил поддержку 32-битных процессоров x86 (i686) 9 ноября 2017 г.
Бен Коттон из Red Hat предложил маркировать и удалять пакеты-пенсионеры при обновлении Fedora 1 3
Доступен традиционный серверный релиз Fedora 27, а проект Modularity будет переосмыслен 15
Arch Linux прекратил поддержку 32-битных процессоров x86 (i686)
Статистика от Steam: Доля Linux-геймеров резко сократилась, составив всего 0,35 % 2
Статистика Linux Foundation по разработке ядра Linux собрала данные о 83 тысячах патчей за год
Дистрибутив Arch Linux начинает переход на systemd 2 7
Последние комментарии
- OlegL, 17 декабря в 15:00 → Перекличка 21
- REDkiy, 8 июня 2023 года в 9:09 → Как «замокать» файл для юниттеста в Python? 2
- fhunter, 29 ноября 2022 года в 2:09 → Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt? 6
- Иванн, 9 апреля 2022 года в 8:31 → Ассоциация РАСПО провела первое учредительное собрание 1
- Kiri11.ADV1, 7 марта 2021 года в 12:01 → Логи catalina.out в TomCat 9 в формате JSON 1
Во-первых, Поттеринг уже заебал. Во-вторых, нахуя?
да фиг с ним арч не жалко.
надеюсь, до слаки это не докатится.
«Yeah, I see a few things coming down the line that may cause a shakeup to our usual way of doing things, and could force Slackware to become, well, perhaps less UNIX-like. I guess the two big ones that are on the horizon are Wayland and systemd. Whether we end up using them or not remains to be seen. It’s quite possible that we won’t end up having a choice in the matter depending on how development that’s out of our hands goes.»
— Patrick Volkerding
если я правильно прочитал все зависит от сообщества…
systemd — система инициализации заменяющая initd. слакварь использует bsd-like систему инициализации…
udev — жалко, его вроде влили в systemd, опять же если правильно понял аглицкие письмена
Мне вот интересно, а про RO-монтированный root они «не, не слышали?»
Да все-равно костыли приходилось подпирать. Типа /etc/mtab или, в Debian < 7, /etc/network/run/ и пр и пр. В текущем тестинге дебиана, кстати, все это учтено. И в /run tmpfs монтируют из коробки. Немного бесит слияние /sbin/ и /usr/sbin/ и /bin/ c /usr/bin/ (проталкиваемое красношляпыми), но и это можно пережить… Обычно, если корень монтируется в RO то и USR туда-же.
с чего это вдруг бесит слияние, все ок. http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
А вы почитайте дальше по треду. Разделение /bin /usr/bin /usr/local/bin — это не бюрократия.
лично я не говорил бюрократия или нет, а дальше по треду ничего особенного и нету, какие-то разьяренные чуваки предлагают удалять cd и монтировать /usr отдельно, в чем профит сложно понять если чесно.
Я имел в виду вот эти 2 поста:
lists.busybox.net/pipermail/busybox/2010-December/074202.html
lists.busybox.net/pipermail/busybox/2010-December/074204.html
Профиты на самом деле от отдельного /usr есть:
да, я про них и написал.
падение фс как-то средневеково звучит, а бэкапы, а клауды и все такое?
«это конечно не столь актуально.»(с)
логическое деление конечно логично, но вот лично мне для удовлетворения «логичности» хватит и /bin /sbin :)
тут не в теме, а вы встраиваете системы?
Бэкап это конечно хорошо. Но люди делятся на две категории — те что их делают и те что их ещё не делают. Это я в смысле, что обычно их делать начинают после того, как что-то грохнулось.
Про облачные сервисы. Угу, с нашим интернетом… сколько будет сливаться средних размеров $HOME в облако? Вот недавно сливал резервную копию с ноутбука, полный бэкап $HOME оказался порядка 40 гигабайт. А куда делать бэкап с домашнего файлохранилища я вообще не представляю.
Так что средневеково или нет, а лучше я минимизирую возможности повреждений и разнесу систему по разным файловым системам.
По поводу логического деления — я для себя открыл /usr/local и /opt на тот случай, когда пакетировать собираемую руками софтину лень, а поставить бы надо. Так что деление вполне логичное (на мой взгляд. Всё ИМХО).
Встраиваемые системы — имеются в виду всяческие приборы, маршрутизаторы и т, д. На предыдущей работе мучать измерительные приборы под linux доводилось. Правда вопрос, в одном каталоге всё держать или в разных не поднимался. Без этого проблем и глюков хватало.
если домашняя система и важное файлохранилище, то как показывает практика UPS+хорошие винчестеры+поддержка этого всего в адекватном состоянии рашеют проблему «некуда сделать бэкап»(ну и привет минимизация возможности повреждений).
сливать в облако $HOME? мне представляется это громоздким решением, доп. винчестер и нет проблем. а по поводу объема вообще какой смысл волноваться, всегда есть rsync.
кстати локальный софт можно и себе в $HOME ставить если что, даже рут прав не нужно:)
а про встраиваемые системы видите как забавно, даже вопрос не встал:)
в итоге как-то и получается что вопрос разделения больше вопрос «ИМХО» чем действительно здравого смысла, ИМХО:)
Вы очень многого хотите, от домашнего пользователя. Я, скажем, последнее время размышляю о том, что стар стал для генту: частота, с которой в моей консоле звучат слова emerge — sync; emerge --update; снизилась до трёх месяцев в минус первой степени. Причём вовсе не на каждое обновление у меня хватает терпения довести до завершённости. Я уж молчу про использование «левых» оверлеев и вручную поддерживаемое содержимое /usr/local/portage. И о каком адекватном состоянии тут может быть речь? И почему я должен ждать, когда же и генту тоже сольёт весь линь в один раздел, чтоб уж либо пан, либо пропал?
Вы говорите «бекапы», «UPS», «хорошие винчестеры», «rsync»… Это издевательство такое?
Куда лить домашние бекапы? Лишнее место на жёстких дисках я, всё же склонен использовать не под рейд 1, а под рейд 0, что лишь снижает надёжность. И кстати в подобных ситуациях, очень удобно иметь маленький раздел под /, который будет выполнен в формате raid 1, что позволит, во-первых, загрузчику легко с ним расправляться, а во-вторых, грузиться даже если рейд упал или покоцана фс. Кстати к «неадекватному состоянию» и raid 0, у меня была история дома, периода когда у меня сыпались жёсткие диски один за другим. Надо заметить, что я никогда не отличался запасливостью, и никаких загрузочных дискет, флешек и прочего хлама я не хранил. Так вот, когда очередной диск вдруг начал падать, а я подпирая его убил линукс до полного нестояния, и всё что я имел — это stage 1.5 grub’а, я уже думал что всё, приехали — надо идти по знакомым, клянчить у них немножко интернета для скачивание какого-нибудь live-cd и cd-привод на время (у меня последний cd-привод сломался в незапамятные времена, всё никак не соберусь купить новый). Но порывшись по разделам из командной строчки grub, я нашёл живой раздел (который я «потерял»: raid1 собранный из двух разделов рассинхронизировался, и один из разделов остался в неприкосновенности), на котором оказался и stage2 и рабочее ядро, и /bin, и /sbin и /lib. Я не очень помню деталей: странно выглядит ситуация, но я точно помню, что я искал и нашёл недостающие части grub и фс с ядром и базовой системой. Описанная ситуация далека от того, на что стоит нацеливаться разработчикам дистрибутива, но тем не менее, я в ней побывал, и ничего хорошего бы не вышло, если бы /bin и /sbin были бы символьными ссылками куда-то в /usr.
Возвращаясь к вашим «панацеям»… UPS? Ну есть у меня UPS, и что с того? Когда я довожу ядро до kernel-panic, никакой UPS не спасает. Как правило, я не забываю предварительно сказать sync, но, надо признаться, иногда ядро паникует совершенно неожиданно для меня.
Вы произносите слово «ИМХО», и не зря произносите: вы рассматриваете некий ограниченный класс ситуаций, в которых плевать, сколько директорий bin на самом деле есть в системе. Здесь на nixp мы уже имели спор на эту тему (извините за лень, но ссылку искать не буду). Тогда меня убедили, что ничего хорошего от слияния не будет. Совершенно ничего хорошего не выходит. А вот неприятные последствия кое-кто огребёт, поскольку гибкость системы снизится. Ну так и на чьём мнении надо ставить штамп «ИМХО»?
И для генту стар, и рейд не такой, и ядро до кернел паника доводить приходиться, и UPS не помогает, жесть ивановна просто! И да, я стараюсь рассматривать некий ограниченный класс ситуаций когда пользователь адекватно умеет оперировать предоставленными инструментами, кто не умеет добро пожаловать в светлый мир macos и windows. А тут в линуксах всегда на крайний случай есть свобода сделать свой дистрибутив с отдельным /usr, блэкджеком и, простите, шлюхами. Сами решайте ИМХО или нет))