В смысле?
В прямом. Нет никакой разницы. Пока.
Дело в том, что отдельные элементы пятой плазмы запускаются из под четвёртых кед. Да, с помощью KF5.
Вы прямо сейчас можете сделать
sudo pacman -S kf5
и Вам ничего за это не будет )))
Плазма не упадёт и разницы Вы не увидите

ЗЫ я на всякий случай уточню, что все таки не testing, а kde-unstable
Угу. Спасибо, что поправил )))

А если плазма выйдет в официальной репе, то ауровский пакет обновится или придётся сносить его?
Какой именно? Если plasma-desktop, то скорее всего он будет конфликтовать с официальными сборками и pacman предложить его заменить.
А так kf5 и plasma-next можно поставить из testing-ветки. Просто в АУРе более свежие версии
Тут уже давно об этом споры идут. Можете почитать )))
Вывод таков - пока сыровато.

Я вот собрал plasma-desktop-git, ну а толку? Работает только в текущих кедах, разве что тема значков поменялась на breeze и шрифты стали тоньше. Примерно вот так. В процессах видно plasma-desktop, если его загасить, остаётся один чёрный фон без панелей и виджетов и окна.
Сегодня скачал и погонял на виртуалке кубунту с пятыми кедами, как-то неочень.
Будем ждать. :)

А рядом был ДНС, что б его !!!!
НИКОГДА не покупайте технику с лэйблом DNS! На вид как г**но, внутри ещё хуже. Дешёвая кетайская комплектуха и низкое качество сборки. Я пока в сервисном центре работал, у нас половина всех заказов была - это продукция DNS, причём какую-то часть этого непотребства даже не принимали в ремонт - типа дешевле закопать!

А по сабжу - поздравляю, и присоединяюсь к вопросу:

ну что как успехи, КДЕ взлетел?

можно ли arch накрутить на сервер
Конечно можно, почему бы и нет?
В этом смысле ARCH мало чем не отличается от других линуксов, главное не боятся systemd )))

если можно установить arch то какие проблемы ждут
Проблемы такие же как и у других дистров - НИКОГДА и НИЧЕГО не ставить из левых репозиториев и других сомнительных мест (AUR в первую очередь)! Также держаться подальше от тестовой ветки - и будет тебе счастье ))) В основной ветке пакеты неплохо протестированы и проблем со стабильностью системы нет.
если кто ставил или держит поможет кто советом
На работе файлопомойка крутится на ARCH`e (FTP+SMB+примитивный брэндмауэр на iptables), работает ровно, ресурсов почти не потребляет (запустил на старом железе, без всяких DE, WM даже Х-ов нет, голая консоль по ssh).
vasek
Кстати да, тоже верный способ

KERNEL=="sd[a-z]1", ATTRS{serial}!="1291822131250060", OPTIONS+="ignore_device"

polkit.addRule(function(action, subject) {
if ((action.id == "org.freedesktop.udisks.filesystem-mount") &&
subject.isInGroup("users")) {
return polkit.Result.YES
Замени YES на AUTH_ADMIN, чтобы запрашивала пароль рута, или вообще NO, чтобы никто не мог смонтировать.
Правила Udev имеют приемущества над правилами polkit, так что не стесняйся )))
А если надо только смонировать флешку, можно и не писать отдельный скрипт, делать прямо в rules'e:
RUN+="mount $devnode /mount/point
Ну и для отладки неплохо смотреть в журнал udev при подключении/отключении флешки:

journalctl -f -u systemd-udevd
Самая распрастраненная ошибка - неправильная пара ключ-значения в правиле
Еще помогает применение правила в "ручном" режиме:
sudo udevadm trigger

одно и то же правило не будет работать для dongle и обычной флэшки
Конечно не будет.
Например, в ключах Guardant, насколько я понимаю, код записан физически на кристале, и чтобы его считать, нужен особый драйвер. Поэтому такие ключи не определяются как блочные устройства, к ним нужен другой подход
Для обычной флэшки алгоритм будет примерно таким:
  1. Запретить монтирование всех сменных носителей
  2. Разрешить только нужную нам флешку

Первая задача решается через policykit.
Создаём файл 30-mount.rules в дирректории /etc/polkit-1/rules.d

$ sudo nano /etc/polkit-1/rules.d/30-mount.rules

// Allow udisks2 to mount devices without authentication
// for users in the "storage" group.
polkit.addRule(function(action, subject) {
 if ((action.id == "org.freedesktop.udisks2.filesystem-mount-system") &&
       subject.isInGroup("users")) {
              return polkit.Result.YES;
                 }
                 });
 polkit.addRule(function(action, subject) {
  if ((action.id == "org.freedesktop.udisks.filesystem-mount") &&
    subject.isInGroup("users")) {
    return polkit.Result.AUTH_ADMIN;
       }
  });
Первое правило для монтирования файловых систем (разделы на локальном диске), второе правило для монтирования внешних накопителей. Возможные значения:
  • YES - всем
  • NO - никому
  • AUTH_ADMIN - с паролем администратора
  • AUTH_SELF - с паролем пользователя
То есть для подключения флешки нужен будет парль root.

Для второй задачи нужно мудет создать правило для udev. Для этого надо узнать атрибуты устройства.
1) Определяем нашу флешку:

$ ls -l /dev/sd*
brw-rw---- 1 root disk 8,  0 июл 22 12:59 /dev/sda
brw-rw---- 1 root disk 8,  1 июл 22 12:59 /dev/sda1
brw-rw---- 1 root disk 8,  2 июл 22 12:59 /dev/sda2
brw-rw---- 1 root disk 8,  3 июл 22 12:59 /dev/sda3
brw-rw---- 1 root disk 8, 16 июл 22 13:43/dev/sdb #нам нужно именно блок устройства, а не раздел
brw-rw---- 1 root disk 8, 17 июл 22 13:43 /dev/sdb1
2) Смотрим атрибуты:

$ udevadm  info  -a -p /sys/block/sdb
# вывод сокращён
 KERNEL=="sdb"
    SUBSYSTEM=="block"
    DRIVER==""
    ATTR{ro}=="0"
    ATTR{size}=="1001472"
    ATTRS{model}=="DataTraveler 2.0"
    ...
    ATTRS{idVendor}=="0930"
   ATTRS{idProduct}=="6533"
3) Пишим правило для UDEV:

#имя пользователя - user
#директория /home/user/mnt должна существовать!
$ sudo nano /etc/udev/rules.d/20-usb-mount.rules
KERNEL=="sd[a-z]1", ATTRS{model}=="DataTraveler 2.0", RUN+="mount $devnode /home/user/mnt "
Т.е. при подключении устройства "DataTraveler 2.0", оно монтируется в /home/user/mnt $devnode - узел устройства вида /dev/sdb1, который назначается ядром в момент подключения.
По идее можно в атрибутах указывать VendorID:ProductID (для однозначного определения устройства), но у меня не сработало :(.
Так же можно запускать свой скрипт, этот вариант гораздо гибче, потому что можно не только монтировать, но и выполнять другие действия (копировать, менять владельца ит.д.). Так как udev выполняется от имени root, то и скрипт будет выполнятся от root`a. Можно также задавать тип доступа к инфе на флешке, например "только для чтения".
Окончательный вариант может быть примерно таким:

$ sudo nano /etc/udev/rules.d/20-usb-mount.rules
KERNEL=="sd[a-z]1     ATTRS{idVendor}=="0930"    ATTRS{idProduct}=="6533"  RUN+="/bin/bash /home/user/bin/usb-mount.sh  $devnode &" MODE=="0444"

$ nano /home/user/bin/usb-mount.sh
mount $1 /home/user/mnt

#в скрипт в качестве переменной передаётся devnode
# & - возвращает управление udev

После этого не забываем применить правило для udev:

$ sudo udevadm  --reload-rules